...
Os nomes dos campos na mensagem única devem respeitar as regras a seguir:
...
Bloco de código | ||
---|---|---|
| ||
"BankCode": { "description": "Código do banco", "type": "integer", "format": "int32" } |
type: integer
...
Bloco de código | ||
---|---|---|
| ||
"BankCode": { "description": "Código do banco", "type": "integer", "format": "int64" } |
type: number
...
Bloco de código | ||
---|---|---|
| ||
"UnitsPerHour": {
"type": "number",
"format": "float"
} |
...
Bloco de código | ||
---|---|---|
| ||
"CreditLimit":{ "type":"number", "format":"double" } |
...
Campos que se repetem poderão apresentar um padrão diferente, consulte o tópico Criando criando listas de valores e elementos para para mais informações.
Havendo a necessidade de validação da presença ou não de informação na mensagem, este controle deve ser feito no próprio adapter.
...
Não existe a necessidade de criar a mensagem Manufacturer (supondo que contém apenas Código + Descrição). Estes dados deverão ser enviados na mensagem de Item.
Exemplo |
---|
Mensagem Item Code Description ManufacturerCode ManufacturerDescription |
Âncora | ||||
---|---|---|---|---|
|
...
Porém, há casos em que um campo em um produto é composto por uma lista fixa de valores, enquanto em outro produto esses valores podem ser cadastrados dinamicamente. Exemplo: Tipo do documento no Logix é fixo; no Protheus é pre-cadastrado e permite alterar; no Datasul é fixo e no RM é totalmente cadastrável. Para estes casos leia o tópico Conflito entre valores fixos e valores cadastráveis.
Bloco de código | ||||
---|---|---|---|---|
| ||||
"SubscriptionType": { "type": "string", "example": "1", "description": "Tipo de inscrição", "enum": ["1", "2", "3", "4"], "x-totvs": [{ "product": "protheus", "field": "SM0.M0_TPINSC", "required": false, "type": "Char", "length": "1", "available": true, "canUpdate": false, "note": "1=CEI;2=CNPJ;3=CPF;4=INCRA" }] } |
...