由于架构设计的原因，业务组或业务员最初被设计成了单据的形式，在新增、修改业务组/业务员的地方，实际上是一张单据，对应的业务组和业务员的信息，是这张单据的单据体信息。然后其他单据上使用业务组或业务员的时候，是从这个单据体里封装出来对应业务组/业务员的基础资料，通过基础资料来使用。如下图所示：

       每次新增业务组/业务员的时候，就是往这个单据的单据体里新增行的操作。业务上做了一个插件的特殊处理，每次在列表点击新增，打开单据的时候，会默认将打开的单据的业务组类型设置成销售组，然后加载当前系统已有的销售组的信息，因此，点击新增时，实际上会变成修改单据的状态，业务员相同。也是因为这个逻辑的存在，业务组或业务员通过API或Excel引入创建时，不能想其他单据一样每次都直接追加导入，需要转换为修改保存（用API时）或覆盖引入（用引入时）的操作进行。

       下面，以业务组为例子，就分步骤详细介绍一下操作过程和注意事项，业务员类似操作。

       当系统初始化时，即当前系统还没有任何的业务组数据，对应的业务组单据也还没有创建。新增第一个类型的业务组，如销售组，此时直接调用API或引入直接新增即可，和其他单据操作相同，此时没有特别之处。第二次新增，如果创建的还是销售组，与第一次创建的业务组类型相同时，也可以直接追加创建，或在已创建好的销售组单据上调用API修改保存新增分录或通过Excel覆盖引入新增分录行都可以。

       重点在于，当新增的类型与已存在的业务组类型与已存在的业务组类型不同时，就需要注意按以下步骤进行，比如系统已经增加了销售组，此时需要新增采购组的场景。

       第一步，在业务组列表，从界面上新手动新增，新增业务组类型为采购组的单据

        界面上手动新增的采购组单据的明细信息中手动新增一到两行即可，这一步主要是要先创建好一张待使用的采购组单据，后续要继续新增的业务组都往这个单据里新增明细信息行。为了方便后续查询，可在单据头的描述字段上写上一个标识文字，作为后续步骤的查询条件。

       对已有的单据做新增行操作，在API的操作上，对应的就是调用保存接口做修改，此时需要在保存接口里传入单据内码做条件的，因此，首先，调用单据查询接口，先获取采购组单据的内码100007

       然后，使用这个业务组单据内码，构建保存接口的Json，做新增行分录，此时，特别需要注意，保存接口的IsDeleteEntry参数必须设置为false，不然会把已存在的分录行删除掉。构建Json时，单据头只需要传业务组内码字段即可，其他单据头字段全都不要，明细信息部分，只需传新增的采购组行信息即可，如以下示例：

{
    "IsDeleteEntry": "false",
    "Model": {
        "FOperatorGroupId": 100007,
         "FEntity": [
            {
                "FEntryId": 0,
                "FBizOrgId": {
                    "FNumber": "101.2"
                },
                "FNumber": "API新增采购组1",
                "FName": "API新增采购组1",
                "FOperatorGroupType_EYR": "CGZ",
                "FIsUse": "true",
                "Fdescription_ETY": "",
                "FSubEntity": [
                    {
                        "FStaffId": {}
                    }
                ]
            }
        ]
    }
}

调用成功之后，就会新增一行采购组，而原来的销售组不受影响。其他要新增的采购组如法炮制操作。

       如果是使用Excel引入做新增，操作过程类似，首先，第一步，现在业务组列表将手动界面新增的采购组单据过滤出来，然后按引入模板引出

       然后在引出来的引入模板上，原来的数据全部都不要动，特别是明细信息里已有的数据行，千万不能删掉，否则覆盖引入会删除掉。接着在明细信息里追加要新增的业务组分录行。

     最后，覆盖引入编辑好的Excel

请问单据查询接口查询到多个内码怎么理解？