Conforme a VTEX já informou por e-mail, teremos que nos adequar até dia 28/fev, como sugestão a VTEX poderia liberar uma listagem DE PARA dos métodos descontinuados para as novas APIs, assim seremos assertivos e mais rápidos na implementação.
Veja abaixo a lista de métodos de Web Service que serão descontinuados:
AddressByAddressClient
AddressGetByClientIdV2
AddressInsertUpdateV3
ClientGet
ClientGetAllFromCreatedDateAndId
ClientGetByCPF
ClientGetByEmailV3
ClientGetByGuidV3
ClientGetV3
ClientInsertUpdateV3
FreightCalculateV3
FreightGetAll
NewsletterGetAllByDate
OrderChangeStatus
OrderChangeTrackingNumber
OrderChangeTrackingNumberV3
OrderGet
OrderGetByClientCpf
OrderGetByStatus
OrderGetByStatusByQuantity
OrderGetNext50FromIdV3
OrderGetV3
OrderPaymentGetAll
OrderStatusGetAll
UpdateNotifyShipping
WareHouseIStockableGetByStockKeepingUnit
WareHouseIStockableGetByStockKeepingUnitV3
WareHouseIStockableUpdate
WareHouseIStockableUpdateV3
ZipCodeGet
OBS: em breve as APIs do catálogo estarão todas prontas. Com isso, descontinuaremos também os métodos de Web Service do Catálogo. Então aproveite para já iniciar também a implementação de integrações por API com o Catálogo.
Desculpem a demora pra aparecer aqui... Nem todo método tem um substituto direto. Em muitos casos pode ser necessária uma revisão na arquitetura de integração.
Os métodos ClientDTO e AddressOrderDTO, por exemplo, não são úteis. Os dados do cliente e seu endereço devem ser lidos diretamente de cada pedido no OMS, exatamente nesse fluxo: help.vtex.com/pt/tutorial/guia-de-integracao-de-erps-pedidos
Tudo relacionado a pedidos, clientes e endereços será coberto com essa documentação.
Para recuperar os dados dos clientes de forma individual, será caso de usar as APIs do Master Data, lendo a entidade CL.
O mesmo para o NewsletterGetAllByDate; os dados do formulário de newsletter devem ser gravados no Master Data e lidos a partir de lá.
Outras integrações:
Estoque = APIs do Logistics
Preços (pricing antigo) = APIs do Rates and Benefits
Oi, Allan! Faz um post só pra isso e me marca que te respondo por lá... É essencial tratarmos apenas um assunto por postagem, pra não perder a visibilidade das diferentes dúvidas que rolam na comunidade. =)
"Desculpem a demora pra aparecer aqui... Nem todo método tem um substituto direto. Em muitos casos pode ser necessária uma revisão na arquitetura de integração."
Existe algum documento com de para do retorno dos dados SOAP para REST do que mudou?
pra saber se teve alguma melhoria:
Exemplo: pegar produto: a lista de "totals" não existia no SOAP ou se existia onde era informado.
Exemplo2 : pegar produto: alguns nomes foram modificados.
Realmente não temos este documento... A parte de pedidos é bem documentada com o artigo que citei, e as outras tendem a ser auto explicativas. Mas estamos à disposição pra qualquer dúvida!
Quanto aos retornos e campos que devem ser usados, é uma grande falha nossa ainda não ter isso documentado... Mas a evolução da documentação do produto é um trabalho em constante andamento, com uma equipe dedicada para isso.
Só fiquei um pouco confuso com as suas dúvidas... Sobre qual API exatamente você está falando? Quais campos você deseja, e não encontrou no retorno?
Só peço que levante essas questões em uma nova postagem, pra não termos um mesmo post com várias dúvidas diferentes. Pode me marcar na nova postagem que lhe retorno em seguida por lá!