Back to Details

building-b2b

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- TIER:1 -->
<!-- TIER:1 -->

Building B2B / EDI Integrations

构建B2B/EDI集成

B2B Manager is Celigo's EDI hub for exchanging structured business documents with trading partners. It handles X12 (ANSI) and EDIFACT (UN) standards over FTP, AS2, and VAN connections.
An EDI integration has these Celigo-specific components:
  • Trading partner connector -- a pre-built template (590+) defining the connection type, EDI profile defaults, and export/import field requirements for a specific trading partner
  • EDI profile -- interchange envelope settings (ISA/GS for X12, UNB for EDIFACT) that identify sender/receiver and control document versioning
  • File definition -- parsing and generation rules that describe the segment/element structure of a specific EDI document type (e.g. Costco 850, Walmart 856)
  • Connection -- FTP, AS2, or VAN credentials for the trading partner's EDI endpoint
  • Exports and imports -- file-based data sources/destinations that use file definitions to parse inbound EDI or generate outbound EDI
  • Flows -- pipelines wiring exports and imports together with transformations
B2B Manager是Celigo的EDI枢纽，用于与贸易伙伴交换结构化业务文档。它支持通过FTP、AS2和VAN连接处理X12（ANSI）和EDIFACT（UN）标准。
EDI集成包含以下Celigo专属组件：
  • 贸易伙伴连接器——预构建模板（590+个），定义了特定贸易伙伴的连接类型、EDI配置文件默认值以及导出/导入字段要求
  • EDI配置文件——交换信封设置（X12为ISA/GS，EDIFACT为UNB），用于识别发送方/接收方并控制文档版本
  • 文件定义——解析和生成规则，描述特定EDI文档类型的段/元素结构（例如Costco 850、Walmart 856）
  • 连接——贸易伙伴EDI端点的FTP、AS2或VAN凭证
  • 导出与导入——基于文件的数据源/目标，使用文件定义解析入站EDI或生成出站EDI
  • 流程——将导出和导入与转换逻辑连接起来的管道

EDI Standards

EDI标准

X12 (ANSI ASC X12) -- North American standard. Documents are transaction sets identified by 3-digit codes (850 = PO, 810 = Invoice, 856 = ASN, 997 = FA, 855 = PO Ack, 846 = Inventory, 860 = PO Change). 50+ additional types supported including healthcare (834/835/837), transportation (204/210/214), and supply chain (753/843/861). Envelope: ISA → GS → ST → segments → SE → GE → IEA. Versions: 4010, 5010, 4030, etc.
EDIFACT (UN/EDIFACT) -- International standard. Documents are messages identified by 6-letter codes (ORDERS, INVOIC, DESADV, ORDRSP, RECADV, INVRPT, PRICAT, CONTRL). Additional messages: INSDES, OSTRPT, PARTIN, DELJIT, PRODAT, DELFOR, SLSRPT. Envelope: UNB → UNH → segments → UNT → UNZ. Versions: D93A, D96A, D01B, etc.
X12（ANSI ASC X12）——北美标准。文档以3位代码标识的交易集形式存在（850=采购订单，810=发票，856=提前发货通知，997=功能确认，855=采购订单确认，846=库存报告，860=采购订单变更）。支持50余种额外类型，包括医疗保健（834/835/837）、运输（204/210/214）和供应链（753/843/861）。信封结构：ISA → GS → ST → 段 → SE → GE → IEA。版本：4010、5010、4030等。
EDIFACT（UN/EDIFACT）——国际标准。文档以6位代码标识的消息形式存在（ORDERS、INVOIC、DESADV、ORDRSP、RECADV、INVRPT、PRICAT、CONTRL）。额外消息类型：INSDES、OSTRPT、PARTIN、DELJIT、PRODAT、DELFOR、SLSRPT。信封结构：UNB → UNH → 段 → UNT → UNZ。版本：D93A、D96A、D01B等。

Quick Reference

快速参考

Resource Decision Matrix

资源决策矩阵

TaskResourceCLI commandSchema
Discover partner templatesTrading partner connector
tp-connectors list
tp-connector-request.yml
Define interchange envelopeEDI profile
edi-profiles create
edi-profile-request.yml
Define document parsing/generationFile definition
file-definitions create
file-definition-request.yml
Monitor document exchangeEDI transaction
edi-transactions list
edi-transaction.yml
Connect to partner endpointConnection (FTP/AS2/VAN)
connections create
See configuring-connections
任务资源CLI命令Schema
发现伙伴模板贸易伙伴连接器
tp-connectors list
tp-connector-request.yml
定义交换信封EDI配置文件
edi-profiles create
edi-profile-request.yml
定义文档解析/生成文件定义
file-definitions create
file-definition-request.yml
监控文档交换EDI交易
edi-transactions list
edi-transaction.yml
连接到伙伴端点连接（FTP/AS2/VAN）
connections create
请查看configuring-connections

Minimum Required Fields

必填字段列表

ResourceRequired
EDI profile (X12)
name
, 
fileType: "edix12"
, 
tpInterchangeId
, 
myInterchangeId
, 
tpIdQualifier
, 
myIdQualifier
, 
tpGroupId
, 
myGroupId
, 
isa12
(version), 
gs07
, 
gs08
EDI profile (EDIFACT)
name
, 
fileType: "edifact"
, 
unb010_0001
, 
unb010_0002
, 
versionNumber
, 
releaseNumber
, 
controllingAgency
File definition
name
, 
version: "2"
, 
format
(e.g. 
delimited/x12
), 
delimited
block (rowSuffix, colDelimiter), 
rules[]
资源必填字段
EDI配置文件（X12）
name
, 
fileType: "edix12"
, 
tpInterchangeId
, 
myInterchangeId
, 
tpIdQualifier
, 
myIdQualifier
, 
tpGroupId
, 
myGroupId
, 
isa12
（版本）, 
gs07
, 
gs08
EDI配置文件（EDIFACT）
name
, 
fileType: "edifact"
, 
unb010_0001
, 
unb010_0002
, 
versionNumber
, 
releaseNumber
, 
controllingAgency
文件定义
name
, 
version: "2"
, 
format
（例如
delimited/x12
）, 
delimited
块（rowSuffix, colDelimiter）, 
rules[]

Schema Index

Schema索引

  • edi-profile-request.yml -- X12 ISA/GS and EDIFACT UNB fields
  • file-definition-request.yml -- format, delimiters, rules structure
  • edi-transaction.yml -- transaction query response shape
  • tp-connector-request.yml -- connector and supportedBy sections
  • tp-supported-by-section.yml -- connection, profile, export/import pre-configuration
  • edi-profile-request.yml——X12 ISA/GS和EDIFACT UNB字段
  • file-definition-request.yml——格式、分隔符、规则结构
  • edi-transaction.yml——交易查询响应结构
  • tp-connector-request.yml——连接器和supportedBy部分
  • tp-supported-by-section.yml——连接、配置文件、导出/导入预配置

Related Skills

相关技能

  • configuring-connections > Quick Reference -- FTP, AS2, and VAN connection types for trading partner endpoints
  • configuring-exports > Quick Reference -- file-based exports that parse inbound EDI using file definitions
  • configuring-imports > Quick Reference -- file-based imports that generate outbound EDI using file definitions
  • building-flows > How to Build a Flow -- wiring EDI exports and imports into flow pipelines
  • writing-scripts > Quick Reference -- preSavePage/postMap hooks for EDI record transformation and validation
<!-- TIER:2 -->
  • configuring-connections > 快速参考——贸易伙伴端点的FTP、AS2和VAN连接类型
  • configuring-exports > 快速参考——使用文件定义解析入站EDI的基于文件的导出
  • configuring-imports > 快速参考——使用文件定义生成出站EDI的基于文件的导入
  • building-flows > 如何构建流程——将EDI导出和导入连接到流程管道
  • writing-scripts > 快速参考——用于EDI记录转换和验证的preSavePage/postMap钩子
<!-- TIER:2 -->

How to Build an EDI Integration

如何构建EDI集成

1. Find the trading partner connector

1. 查找贸易伙伴连接器

Trading partner connectors are pre-built templates (590+) that define connection type, EDI profile defaults, and export/import config for a specific partner.
bash
celigo tp-connectors list
celigo tp-connectors get <connectorId>
The connector's 
supportedBy
object tells you what's pre-configured and what the user must provide for the connection, EDI profile, and exports/imports. See tp-supported-by-section.yml for the full structure.
If no connector exists, build the connection, EDI profile, and file definitions from scratch.
贸易伙伴连接器是预构建模板（590+个），定义了特定伙伴的连接类型、EDI配置文件默认值以及导出/导入配置。
bash
celigo tp-connectors list
celigo tp-connectors get <connectorId>
连接器的
supportedBy
对象会告知您哪些内容已预配置，以及用户必须为连接、EDI配置文件和导出/导入提供哪些内容。完整结构请查看tp-supported-by-section.yml。
如果没有可用连接器，则从头开始构建连接、EDI配置文件和文件定义。

2. Check for existing resources

2. 检查现有资源

Before creating anything, check what the account already has. EDI profiles are per-partner (one profile covers all document types), so duplicates waste control number sequences.
bash
celigo account search "<partner-name>"
celigo edi-profiles list | grep -i "<partner-name>"
celigo file-definitions list | grep -i "<partner-name>"
celigo connections list | grep -i "<partner-name>"
在创建任何资源之前，先检查账户中已有的内容。EDI配置文件是按伙伴划分的（一个配置文件涵盖所有文档类型），因此重复创建会浪费控制编号序列。
bash
celigo account search "<partner-name>"
celigo edi-profiles list | grep -i "<partner-name>"
celigo file-definitions list | grep -i "<partner-name>"
celigo connections list | grep -i "<partner-name>"

3. Create the connection

3. 创建连接

Create an FTP, AS2, or VAN connection for the trading partner. Use the connector's 
supportedBy.connection
for pre-configured fields. See configuring-connections for full connection setup.
bash
celigo connections create < connection.json
celigo connections ping <connectionId>
为贸易伙伴创建FTP、AS2或VAN连接。使用连接器的
supportedBy.connection
获取预配置字段。完整连接设置请查看configuring-connections。
bash
celigo connections create < connection.json
celigo connections ping <connectionId>

4. Create the EDI profile

4. 创建EDI配置文件

The EDI profile defines the interchange envelope -- ISA/GS segments (X12) or UNB segment (EDIFACT). Read edi-profile-request.yml for all fields.
Key X12 fields: 
tpInterchangeId
/
myInterchangeId
(ISA06/ISA08), 
tpIdQualifier
/
myIdQualifier
(ISA05/ISA07, e.g. ZZ = mutually defined), 
isa12
(version, e.g. 00401), 
isa15
(P = production, T = test), 
controlNumber
(auto-incremented).
bash
celigo edi-profiles create < profile.json
EDI配置文件定义了交换信封——X12的ISA/GS段或EDIFACT的UNB段。所有字段请查看edi-profile-request.yml。
X12关键字段：
tpInterchangeId
/
myInterchangeId
（ISA06/ISA08）、
tpIdQualifier
/
myIdQualifier
（ISA05/ISA07，例如ZZ=双方约定）、
isa12
（版本，例如00401）、
isa15
（P=生产环境，T=测试环境）、
controlNumber
（自动递增）。
bash
celigo edi-profiles create < profile.json

5. Create file definitions

5. 创建文件定义

Each document type (850, 810, 856, etc.) needs its own file definition with parsing/generation rules. Read file-definition-request.yml for the rules structure.
Key fields: 
format
(
delimited/x12
or 
delimited/edifact
), 
globalId
(standard template reference, immutable), 
delimited.rowSuffix
(segment terminator, 
~
for X12), 
delimited.colDelimiter
(element separator, 
*
for X12), 
rules[]
(hierarchical segment/element tree).
bash
celigo file-definitions create < filedef.json
每种文档类型（850、810、856等）都需要单独的文件定义，包含解析/生成规则。规则结构请查看file-definition-request.yml。
关键字段：
format
（
delimited/x12
或
delimited/edifact
）、
globalId
（标准模板引用，不可变）、
delimited.rowSuffix
（段终止符，X12为
~
）、
delimited.colDelimiter
（元素分隔符，X12为
*
）、
rules[]
（分层段/元素树）。
bash
celigo file-definitions create < filedef.json

6. Create exports and imports

6. 创建导出和导入

Inbound EDI export (reading from FTP/AS2): 
adaptorType: "FTPExport"
, 
file.type: "filedefinition"
, 
file.fileDefinition._fileDefinitionId
, 
_ediProfileId
, 
ftp.directoryPath
.
Outbound EDI import (writing to FTP/AS2): 
adaptorType: "FTPImport"
, same file definition and profile references.
See configuring-exports and configuring-imports for full field schemas.
入站EDI导出（从FTP/AS2读取）：
adaptorType: "FTPExport"
, 
file.type: "filedefinition"
, 
file.fileDefinition._fileDefinitionId
, 
_ediProfileId
, 
ftp.directoryPath
。
出站EDI导入（写入FTP/AS2）：
adaptorType: "FTPImport"
，引用相同的文件定义和配置文件。
完整字段Schema请查看configuring-exports和configuring-imports。

7. Wire into flows

7. 连接到流程

Typical patterns:
  • Inbound: FTP export (parse EDI) → transform EDI fields to ERP → ERP import
  • Outbound: ERP export → transform to EDI → FTP import (generate EDI)
  • 997 FA: auto-generate from 
    file.faAcknowledgement: true
    on the inbound export
See building-flows for scheduling, chaining, and error management.
典型模式：
  • 入站：FTP导出（解析EDI）→ 将EDI字段转换为ERP格式 → ERP导入
  • 出站：ERP导出 → 转换为EDI格式 → FTP导入（生成EDI）
  • 997功能确认：在入站导出上设置
    file.faAcknowledgement: true
    自动生成
调度、链式调用和错误管理请查看building-flows。

Document Grammar vs Partner Identity

文档语法与伙伴身份

The most important conceptual split in Celigo's EDI model:
  • The file definition owns the document grammar -- the segments, elements, loops, and envelope structure of one document type (850, 810, ORDERS), one per document type and direction.
  • The EDI profile owns the partner identity -- the interchange IDs, qualifiers, group IDs, version, and control settings that fill that envelope. One profile per trading partner, per EDI standard, no matter how many document types you exchange.
The two meet at runtime. Envelope elements in a file definition's rules don't hardcode identity values -- they carry 
{{{ediProfile.…}}}
references, and the platform substitutes the values from the profile linked on the export/import (
_ediProfileId
). On parse (inbound), the substituted values are validated against the actual file bytes -- a mismatch fails the document with an EDI-profile validation error (an identity problem, not a grammar problem). On generate (outbound), the values are written into the envelope of the file being produced.
A file-based EDI step therefore needs both resources: the platform rejects an X12/EDIFACT file definition that has no linked profile. Sequence the profile before the exports/imports that reference it, exactly as you would a connection.
Celigo EDI模型中最重要的概念区分：
  • 文件定义负责文档语法——一种文档类型（850、810、ORDERS）的段、元素、循环和信封结构，每种文档类型及方向对应一个文件定义。
  • EDI配置文件负责伙伴身份——填充信封所需的交换ID、限定符、组ID、版本和控制设置。每个贸易伙伴、每种EDI标准对应一个配置文件，无论交换多少种文档类型。
两者在运行时结合。文件定义规则中的信封元素不会硬编码身份值——它们携带
{{{ediProfile.…}}}
引用，平台会替换为导出/导入中链接的配置文件（
_ediProfileId
）的值。在解析（入站）时，替换后的值会与实际文件字节进行验证——不匹配会导致文档因EDI配置文件验证错误而失败（属于身份问题，而非语法问题）。在生成（出站）时，值会写入生成文件的信封中。
因此，基于文件的EDI步骤需要同时具备这两种资源：平台会拒绝未链接配置文件的X12/EDIFACT文件定义。请先创建配置文件，再创建引用它的导出/导入，就像处理连接一样。

One Profile, Both Directions

一个配置文件，双向使用

A profile is direction-agnostic. Its fields are labeled by whose identity they hold (
tp*
vs 
my*
), not by sender/receiver position. On an inbound parse the partner is the sender, so the file definition's rules bind the sender slots to the 
tp*
values and the receiver slots to 
my*
; on an outbound generate the orientation flips (sender → 
my*
, receiver → 
tp*
). One partner profile serves the 850s coming in and the 810s going out. This is a notable asymmetry with file definitions, which come in separate parse and generate variants per document type -- parse rules tolerate what partners send, generate rules must produce exactly what partners require.
配置文件与方向无关。其字段按所属身份标记（
tp*
vs 
my*
），而非发送方/接收方位置。在入站解析时，伙伴是发送方，因此文件定义规则会将发送方插槽绑定到
tp*
值，接收方插槽绑定到
my*
值；在出站生成时，方向反转（发送方→
my*
，接收方→
tp*
）。一个伙伴配置文件可同时处理传入的850和传出的810。这与文件定义形成明显不对称：文件定义针对每种文档类型有单独的解析和生成变体——解析规则兼容伙伴发送的内容，生成规则必须严格符合伙伴要求。

Sourcing EDI Resources

EDI资源获取

Generating an EDI Profile from a Sample File

从示例文件生成EDI配置文件

The fastest correct path to a new profile is not hand-copying values out of a companion guide -- it's parsing a real file. Given a sample EDI file from the partner, the platform reads the interchange envelope (ISA/GS for X12, UNB for EDIFACT -- the standard is auto-detected from the first characters) and extracts the envelope fields into a ready-to-review profile.
  • Review the extracted values before creating -- especially the usage indicator (
    isa15
    , 
    T
    vs 
    P
    ) and the qualifiers -- since they reflect that one file.
  • The extraction produces no 
    name
    ; supply one, favoring the partner-name convention (e.g. "Acme Corp X12").
  • A file the partner sent you has the partner in the sender slots. When it's ambiguous, confirm which direction the sample flows -- what you receive vs what you must produce.
创建新配置文件最快最准确的方式不是从配套手册中手动复制值——而是解析真实文件。给定伙伴提供的EDI示例文件，平台会读取交换信封（X12为ISA/GS，EDIFACT为UNB——标准会从首字符自动检测），并将信封字段提取为可直接审核的配置文件。
  • 创建前请审核提取的值——尤其是使用指示器（
    isa15
    ，T vs P）和限定符——因为它们仅反映该单个文件的设置。
  • 提取结果不包含
    name
    ；请提供一个名称，建议采用伙伴名称命名规范（例如"Acme Corp X12"）。
  • 伙伴发送给您的文件中，伙伴位于发送方插槽。当存在歧义时，请确认示例文件的流向——是您接收的还是您需要生成的。

Never Start EDI from Scratch -- Begin from a Template

永远不要从头开始构建EDI——从模板开始

Celigo ships a global catalog of pre-built EDI templates -- X12 and EDIFACT document definitions, many vendor-specific (per-retailer 850 variants and the like), each tagged with vendor, document type, and direction. Templates are instantiated into account-level file definitions, which you then customize to the partner's companion guide. Canonical sourcing order:
  1. An account-level file definition of the same document type already exists → reuse it or use it as the base.
  2. A global template matches → instantiate it into the account and customize from there.
  3. Build from scratch → last resort, for documents no template covers.
Same-type rule: a file definition is only a valid base for the same transaction set type. An existing 850 is a fine starting point for another partner's 850; an 860 is not a starting point for an 850 -- different documents, different segment structures. Hand-building a rules tree when a template exists invites subtle mistakes in envelope close rules and element conventions.
For onboarding a whole partner (not just one document), prefer a trading partner connector -- it provisions the connection, export, import, and EDI profile together with the partner-specific fields the user must set (see step 1). Build individual EDI steps directly only when adding one document flow against an already-onboarded partner.
Celigo提供全球预构建EDI模板目录——X12和EDIFACT文档定义，其中许多是特定供应商的（例如各零售商的850变体），每个模板都标记了供应商、文档类型和方向。模板会被实例化为账户级文件定义，然后您可以根据伙伴的配套手册进行自定义。标准获取顺序：
  1. 账户中已存在相同文档类型的文件定义→复用它或以此为基础。
  2. 存在匹配的全局模板→将其实例化到账户中并进行自定义。
  3. 从头构建→最后选择，适用于无模板覆盖的文档。
同类型规则：文件定义仅能作为相同交易集类型的基础。现有850可作为另一个伙伴850的起点；而860不能作为850的起点——不同文档的段结构不同。当存在模板时手动构建规则树，容易在信封关闭规则和元素约定中出现细微错误。
对于完整伙伴入驻（而非仅单个文档），优先使用贸易伙伴连接器——它会同时预配连接、导出、导入和EDI配置文件，并标记用户必须设置的伙伴特定字段（请查看步骤1）。仅当为已入驻的伙伴添加单个文档流程时，才直接构建独立的EDI步骤。

Functional Acknowledgements (997 / CONTRL)

功能确认（997 / CONTRL）

Functional acknowledgements -- 
997
(X12) and 
CONTRL
(EDIFACT) -- are how EDI parties confirm receipt of an interchange. They are ordinary file definitions with the 
documentType
field set (
997
or 
CONTRL
), not a separate resource type. Accounts exchanging EDI typically wire them in both directions: generate an acknowledgement for every interchange you receive, and parse the acknowledgements your partner returns for the documents you send.
The generate side can be automated on the inbound export -- set 
file.faAcknowledgement: true
so the platform emits the 997/CONTRL for each parsed interchange (see step 7). Track acknowledgement state per document via 
faStatus
(see Monitoring EDI Transactions).
功能确认——
997
（X12）和
CONTRL
（EDIFACT）——是EDI各方确认收到交换的方式。它们是普通文件定义，仅设置了
documentType
字段（
997
或
CONTRL
），而非单独的资源类型。交换EDI的账户通常会在双向配置它们：为收到的每个交换生成确认，并解析伙伴返回的针对您发送文档的确认。
生成端可在入站导出上自动化——设置
file.faAcknowledgement: true
，平台会为每个解析的交换生成997/CONTRL（请查看步骤7）。通过
faStatus
跟踪每个文档的确认状态（请查看监控EDI交易）。

Strict Validation and the Skip Flags

严格验证与跳过标志

EDI parsing validates inbound files against both the EDI standard and the linked profile. Two file-definition flags relax that:
  • skipEDIValidation
    -- skip structural validation against the EDI standard.
  • skipEDIProfileValidation
    -- skip validation of the envelope against the linked EDI profile.
They exist because real-world partners send files that violate the standard or mismatch the declared profile. Treat them as a pragmatic escape hatch, not a default: prefer fixing the rules (or the profile) so validation passes -- it catches real partner errors. Reach for the skip flags only when a partner's non-conformance is confirmed, acknowledged, and not going to be fixed on their side.
EDI解析会针对EDI标准和链接的配置文件验证入站文件。文件定义有两个标志可放宽验证：
  • skipEDIValidation
    ——跳过针对EDI标准的结构验证。
  • skipEDIProfileValidation
    ——跳过针对链接EDI配置文件的信封验证。
这些标志存在的原因是实际场景中伙伴发送的文件可能违反标准或与声明的配置文件不匹配。请将它们视为实用的应急方案，而非默认设置：优先修复规则（或配置文件）使验证通过——这能捕获真实的伙伴错误。仅当确认伙伴的不符合行为已被认可且对方不会修复时，才使用跳过标志。

Monitoring EDI Transactions

监控EDI交易

B2B Manager tracks every EDI document processed. Key transaction fields: 
documentType
, 
documentNumber
, 
direction
(Inbound/Outbound), 
faStatus
(inProgress/notApplicable/notReceived/received/rejected), 
controlNumber
, 
s3Key
/
_flowJobId
(for raw file download).
bash
celigo edi-transactions list
celigo edi-transactions list --file-type EDIFACT
celigo edi-transactions list --start-date 2026-01-01 --end-date 2026-01-31
B2B Manager会跟踪所有处理过的EDI文档。关键交易字段：
documentType
、
documentNumber
、
direction
（入站/出站）、
faStatus
（处理中/不适用/未收到/已收到/已拒绝）、
controlNumber
、
s3Key
/
_flowJobId
（用于原始文件下载）。
bash
celigo edi-transactions list
celigo edi-transactions list --file-type EDIFACT
celigo edi-transactions list --start-date 2026-01-01 --end-date 2026-01-31

CLI Commands

CLI命令

EDI Profiles

EDI配置文件

bash
celigo edi-profiles list
celigo edi-profiles get <id>
celigo edi-profiles create < profile.json
celigo edi-profiles update <id> < profile.json
celigo edi-profiles set <id> <key>=<value> [<key2>=<value2> ...]
celigo edi-profiles delete <id>
bash
celigo edi-profiles list
celigo edi-profiles get <id>
celigo edi-profiles create < profile.json
celigo edi-profiles update <id> < profile.json
celigo edi-profiles set <id> <key>=<value> [<key2>=<value2> ...]
celigo edi-profiles delete <id>

File Definitions

文件定义

bash
celigo file-definitions list
celigo file-definitions get <id>
celigo file-definitions create < filedef.json
celigo file-definitions update <id> < filedef.json
celigo file-definitions set <id> <key>=<value> [<key2>=<value2> ...]
celigo file-definitions delete <id>
bash
celigo file-definitions list
celigo file-definitions get <id>
celigo file-definitions create < filedef.json
celigo file-definitions update <id> < filedef.json
celigo file-definitions set <id> <key>=<value> [<key2>=<value2> ...]
celigo file-definitions delete <id>

Trading Partner Connectors

贸易伙伴连接器

bash
celigo tp-connectors list
celigo tp-connectors get <id>
celigo tp-connectors list
bash
celigo tp-connectors list
celigo tp-connectors get <id>
celigo tp-connectors list

EDI Transactions

EDI交易

bash
celigo edi-transactions list
celigo edi-transactions list --file-type EDIFACT
celigo edi-transactions list --start-date <date> --end-date <date>
celigo edi-transactions list --limit <n>
bash
celigo edi-transactions list
celigo edi-transactions list --file-type EDIFACT
celigo edi-transactions list --start-date <date> --end-date <date>
celigo edi-transactions list --limit <n>

Downloading EDI Files

下载EDI文件

bash
celigo jobs download-files <jobId>
celigo jobs download-files <jobId> --file-id <s3Key> -o output.edi
<!-- TIER:3 -->
bash
celigo jobs download-files <jobId>
celigo jobs download-files <jobId> --file-id <s3Key> -o output.edi
<!-- TIER:3 -->

Pre-Submit Checklist

提交前检查清单

  • EDI profile uses correct 
    fileType
    (
    edix12
    or 
    edifact
    ) -- immutable after creation
  • ISA IDs padded correctly (15 chars, right-padded with spaces)
  • File definition 
    format
    matches standard (
    delimited/x12
    or 
    delimited/edifact
    )
  • File definition 
    globalId
    references the correct standard template -- immutable after creation
  • Inbound exports do NOT use 
    type: "blob"
    (skips parsing)
  • controlNumber
    starts at 1 unless the partner requires a specific sequence
  • Exports/imports reference both 
    _fileDefinitionId
    and 
    _ediProfileId
  • File definition sourced from a same-type template or existing definition, not hand-built from scratch
  • skipEDIValidation
    / 
    skipEDIProfileValidation
    left off unless partner non-conformance is confirmed and acknowledged
  • File definition used only for marker-based, fixed-width, or EDI files -- plain same-column CSVs use the step's 
    file.csv
    options; JSON/XML/XLSX use step-level parser config
  • Checked what else references a shared file definition (
    celigo account dependencies
    ) before editing it -- cloned instead when the change serves only one consumer
  • EDI配置文件使用正确的
    fileType
    （
    edix12
    或
    edifact
    ）——创建后不可变
  • ISA ID填充正确（15字符，右侧补空格）
  • 文件定义
    format
    与标准匹配（
    delimited/x12
    或
    delimited/edifact
    ）
  • 文件定义
    globalId
    引用正确的标准模板——创建后不可变
  • 入站导出未使用
    type: "blob"
    （会跳过解析）
  • controlNumber
    从1开始，除非伙伴要求特定序列
  • 导出/导入同时引用
    _fileDefinitionId
    和
    _ediProfileId
  • 文件定义源自同类型模板或现有定义，而非手动从头构建
  • skipEDIValidation
    / 
    skipEDIProfileValidation
    仅在确认并认可伙伴不符合行为时启用，否则保持关闭
  • 文件定义仅用于标记型、固定宽度或EDI文件——普通同列CSV使用步骤的
    file.csv
    选项；JSON/XML/XLSX使用步骤级解析器配置
  • 编辑共享文件定义前，先检查哪些资源引用了它（
    celigo account dependencies
    ）——当变更仅服务于一个使用者时，克隆后再修改

Gotchas

注意事项

  1. EDI profiles are per-partner, not per-document-type. One profile covers all document types for a given partner. Search by partner name, not document type.
  2. ISA IDs are right-padded to 15 characters. The API returns them padded; trimming is the caller's responsibility.
  3. fileType
    and 
    globalId
    are immutable after creation.     Create a new resource if you need a different standard or template.
  4. File definitions differ by trading partner. A Costco 850 and a Walmart 850 have different structures. Always use the correct partner-specific definition.
  5. Inbound vs outbound definitions are different. Parsing and generation rules for the same document type are not interchangeable.
  6. Do not set 
    file.type: "filedefinition"
    without a valid 
    _fileDefinitionId
    .     Create without the 
    file
    property and link afterward.
  7. FTP/AS2 exports must not use 
    type: "blob"
    for EDI.     Blob mode skips parsing -- omit the 
    type
    field so the file definition parser runs.
  8. controlNumber
    auto-increments.     Don't reset unless the partner requires it; duplicates cause rejections.
  9. 997 FAs are tracked per-transaction via 
    faStatus
    . Auto-generate with 
    file.faAcknowledgement: true
    on the inbound export.
  10. EDI transactions require an EDI license. 
    edi-transactions list
    only works for accounts with B2B Manager enabled.
  11. skipEDIValidation
    / 
    skipEDIProfileValidation
    are escape hatches, not defaults.     They skip validation against the standard and against the linked profile, respectively. Prefer fixing the rules or the profile; reach for them only when partner non-conformance is confirmed, acknowledged, and won't be fixed on their side.
  12. Never hand-build an EDI file definition when a template exists. Instantiate the matching global template (same document type and direction) and customize. A file definition is only a valid base for the same transaction set type -- an 850 for another 850, never an 860 for an 850.
  13. Functional acknowledgements are file definitions. 
    997
    (X12) and 
    CONTRL
    (EDIFACT) are file definitions with 
    documentType
    set, typically wired in both directions -- generate one for each interchange received, parse the ones the partner returns.
  14. File definitions are shared resources -- an edit hits every referencing step. Several exports/imports can point at the same definition (a partner's inbound 850 export and a re-process flow, or many flows generating one house format). If the change corrects the grammar for everyone (companion-guide update, mis-declared segment), edit in place. If it serves one consumer (a one-partner variant), clone the definition, modify the clone, and re-link only that step. Check what references the definition (
    celigo account dependencies
    ) before editing or deleting.
  15. A marker-less CSV is not a file-definition job. The structured file parser expects a literal row-type marker on every row (
    HDR
    /
    LIN
    , 
    A
    /
    B
    ), fixed-width slices, or EDI envelopes -- feeding it a plain same-column CSV parses wrong, typically collapsing everything into a single record. Plain CSV/TSV belongs to the step's 
    file.csv
    options (
    hasHeaderRow
    , delimiters); JSON, XML, and XLSX belong to step-level parser config, never a file definition.
  1. EDI配置文件按伙伴划分，而非按文档类型。一个配置文件涵盖给定伙伴的所有文档类型。请按伙伴名称搜索，而非文档类型。
  2. ISA ID右侧补空格至15字符。API返回的ID已填充；调用方需自行处理修剪。
  3. fileType
    和
    globalId
    创建后不可变    。若需要不同标准或模板，请创建新资源。
  4. 文件定义因贸易伙伴而异。Costco 850和Walmart 850的结构不同。请始终使用正确的伙伴专属定义。
  5. 入站与出站定义不同。同一文档类型的解析和生成规则不可互换。
  6. 请勿在未提供有效
    _fileDefinitionId
    的情况下设置
    file.type: "filedefinition"
    。创建时不包含
    file
    属性，之后再链接。
  7. FTP/AS2导出处理EDI时不得使用
    type: "blob"
    。Blob模式会跳过解析——请省略
    type
    字段，以便运行文件定义解析器。
  8. controlNumber
    自动递增    。除非伙伴要求，否则请勿重置；重复值会导致被拒绝。
  9. 997功能确认通过
    faStatus
    按交易跟踪。在入站导出上设置
    file.faAcknowledgement: true
    自动生成。
  10. EDI交易需要EDI许可证。
    edi-transactions list
    仅对启用B2B Manager的账户有效。
  11. skipEDIValidation
    / 
    skipEDIProfileValidation
    是应急方案，而非默认设置    。它们分别跳过针对标准和链接配置文件的验证。优先修复规则或配置文件；仅在确认伙伴不符合行为已被认可且对方不会修复时使用。
  12. 当存在模板时，永远不要手动构建EDI文件定义。实例化匹配的全局模板（相同文档类型和方向）并进行自定义。文件定义仅能作为相同交易集类型的基础——850用于另一个850，绝不能用860作为850的基础。
  13. 功能确认是文件定义。
    997
    （X12）和
    CONTRL
    （EDIFACT）是设置了
    documentType
    的文件定义，通常双向配置——为收到的每个交换生成一个，解析伙伴返回的确认。
  14. 文件定义是共享资源——编辑会影响所有引用它的步骤。多个导出/导入可指向同一个定义（伙伴的入站850导出和重新处理流程，或多个生成同一内部格式的流程）。如果变更为所有人修正了语法（配套手册更新、错误声明的段），可直接编辑。如果变更仅服务于一个使用者（单个伙伴的变体），请克隆定义，修改克隆版本，仅重新链接该步骤。编辑或删除前，请检查哪些资源引用了该定义（
    celigo account dependencies
    ）。
  15. 无标记的CSV不属于文件定义任务。结构化文件解析器要求每行都有文字行类型标记（
    HDR
    /
    LIN
    、
    A
    /
    B
    ）、固定宽度切片或EDI信封——传入普通同列CSV会解析错误，通常会将所有内容合并为单个记录。普通CSV/TSV应使用步骤的
    file.csv
    选项（
    hasHeaderRow
    、分隔符）；JSON、XML和XLSX应使用步骤级解析器配置，而非文件定义。