Este documento apresenta as diretrizes para a integração entre sistemas e o ERP Iniflex, fornecendo um guia estruturado para facilitar a comunicação entre plataformas de maneira segura e eficiente.
\nPara garantir a segurança e integridade dos dados, cada projeto requer uma autenticação específica. O acesso é concedido mediante solicitação à Projedata ou diretamente ao cliente, sendo utilizado o modelo Bearer Token como padrão de autenticação.
\nAlém disso, o endereço de IP utilizado será definido conforme a infraestrutura de rede do cliente, podendo ser interno ou externo. Essa definição deve ser avaliada para garantir conformidade e estabilidade na integração. O padrão de requisição segue a estrutura:
\nhttps://{ip:porta}/api/v1/runtime/endpoint/integracao/iniflex/json
\nPara gerar o token na base do cliente, siga os passos abaixo:
\nAcesse a tela PINT002 (Cadastro de Integrações);
\nCrie um novo grupo com a descrição correspondente à integração, selecionando o campo \"Tipo\" como \"PL/SQL\";
\nVincular um usuário que será associado às requisições. Recomenda-se criar um usuário com o nome do software para garantir o registro adequado nos logs;
\nClique no botão verde para gerar o token. Ele ficará disponível no campo \"Chave\".
\nPara que as integrações operem corretamente, é fundamental que o ERP Iniflex esteja atualizado para sua versão mais recente.
\nCaso necessário, a Projedata pode auxiliar na análise e atualização do ambiente.
\nOs endpoints desta API foram projetados para atender diferentes cenários de integração, permitindo que os dados sejam processados de forma eficiente e organizada. Como padrão, todas as requisições utilizam o método POST, respeitando a nomenclatura de cada endpoint:
\nExp (Exportação) – Indica o envio de dados para fora do ERP.
\nImp (Importação) – Indica a entrada de dados no ERP.
\nOs filtros disponíveis possibilitam um refinamento estratégico das informações retornadas, permitindo que cada integração seja personalizada conforme a necessidade do cliente.
\nPara otimizar o desempenho e evitar sobrecarga nos servidores, recomendamos o uso de filtros adequados ao requisitar dados. Requisições amplas ou sem critérios podem impactar na performance da API e no processamento das informações.
\nO software devidamente homologado poderá acessar outras APIs, não estando restrito apenas àquelas listadas a seguir.
\nCRM
\nSoftwares homologados:
\nClicheria
\nSoftwares homologados:
\nCompras
\nSoftwares homologados:
\nMES (sistema de execução de manufatura)
\nSoftwares homologados:
\nO modelo de pré-cliente é amplamente utilizado nos casos em que não se dispõe de uma estrutura robusta de informações do cliente, sendo necessário complementá-las posteriormente. Dessa forma, ao adotar este procedimento, torna-se imprescindível que o usuário conclua o cadastro do cliente diretamente no ERP.
\nOs dados inseridos serão destinados ao cadastro de pré-clientes (PCRM005).
\n(Este método foi adotado devido à necessidade de preenchimento de alguns campos obrigatórios no cadastro de correntistas no Iniflex, de modo que desta maneira a integração não exija tais campos).
\nAs operações permitidas incluem inserção, atualização e remoção, respeitando os critérios estabelecidos para cada método.
\nO campo CNPJ_CPF será utilizado para realizar o mapeamento dos dados entre os sistemas, garantindo que, caso um CNPJ_CPF já esteja cadastrado na base do Iniflex, as informações sejam devidamente atualizadas conforme o envio do arquivo JSON.
\nOutro aspecto relevante para o processo é o campo REMOVE_REGISTRO, o qual determinará se o registro em questão deverá ser removido.
\nTodos os retornos de sucesso possuem o status 200. Dessa forma, para distinguir possíveis erros de negócio, serão utilizados prefixos específicos para identificação das mensagens.
\nERRO# = quando houver um erro por regra de negócio, será retornado o prefixo ERRO# mensagem
\nPRE_CLIENTE# = retornará este prefixo, quando incluso um novo pré-cliente, assim ficará PRE_CLIENTE# codigo do pré cliente gerado
\nAs propostas são comumente utilizadas para registrar o inicio de uma negociação ainda não firmada. Por se tratarem de negociações ainda não concretizadas, algumas informações para o avanço da operação passa a não ser obrigatório, como o cadastro prévio do item, e o cadastro completo do cliente (pode-se utilizar pré-cliente).
\nOs dados inseridos serão destinados ao cadastro de propostas (PVEN013).
\nPoderão serem feitos três operações, INSERÇÃO, ATUALIZAÇÃO e REMOÇÃO, respeitando os critérios de cada método.
\nNeste processo será utilizado o campo PROPOSTA_TERCEIRO para mapear os dados entre ambos os sistemas, de forma que quando houver um PROPOSTA_TERCEIRO já cadastrado na base do Iniflex, os dados serão atualizados conforme o envio do JSON. Outro ponto importante para o processo é o campo REMOVE_REGISTRO, este campo definirá se o registro em questão será removido.
\nAs informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\n#ERRO# = quando houver um erro por regra de negócio, será retornado o prefixo #ERRO#mensagem_do_erro
\n#PROPOSTA# = retornará este prefixo, quando incluso uma nova proposta, assim ficará #PROPOSTA#codigo_ da_proposta
\nEste endpoint permite que seja realizado a movimentação de ordem de serviço interna, considerando os fluxos desenhados em cada cliente.
\nOs dados inseridos serão destinados a repasse da ordem de serviço (PWKF008).
\nNeste endpoint não há conceito de exclusão ou alteração de dados, visto que os repasses seguem sempre um caminho pré definido dentro do ERP.
\nUm ponto importante, é o campo custo_producao, quando o mesmo estiver informado, atualizará na base do cliente, o campo \"Custo Produção\" vinculado ao acessório da OS.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nEste endpoint permite que seja realizado operações para manipular as diversas caracteristicas de um produto com base na ficha técnica pre-existente no ERP.
\nOs dados inseridos serão destinados a ficha técnica dos itens de produção (PPCP017).
\nSão permitidos as operações de inserção, atualização e remoção, respeitando as seguintes regras:
Quando a tag REMOVE_REGISTRO estiver como S, a requisição efetuará a remoção do registro conforme os dados que estão sendo enviados, caso a tag esteja como N ou nula, o registro será inserido, porém caso a mesma chave já seja identificado no ERP, os dados serão atualizados.
As informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nEste endpoint permite que sejam manipulados caracteristicas com base em ordens de produção.
\nOs dados inseridos serão destinados a ficha técnica das ordens de produção (PPCP022).
\nSão permitidos as operações de inserção, atualização e remoção, respeitando as seguintes regras:
Quando a tag REMOVE_REGISTRO estiver como S, a requisição efetuará a remoção do registro conforme os dados que estão sendo enviados, caso a tag esteja como N ou nula, o registro será inserido, porém caso a mesma chave já seja identificado no ERP, os dados serão atualizados.
As informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nNeste endpoint são cadastrado o motivo de parada e o seu vinculo com as etapas.
\nOs dados inseridos serão destinados a cadastro de motivos de parada (PPCP013).
\nNeste processo somente é permitido a inserção ou atualização do motivo de parada, sendo que
a atualização ocorrerá quando o código já exibir no Iniflex. Porém, para as etapas serão permitidas as três operações, inserção, atualização e remoção, de acordo com o campo REMOVE_ETAPA, quando o campo estiver como S, será removido a etapa informada, caso seja N ou nulo, será inserido ou atualizado de acordo se o registro já exisitir no Iniflex.
As informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nEste endpoint permite o cadastro de grupo de motivos de paradas.
\nOs dados inseridos serão destinados ao cadastro de grupo de motivos de parada (PPCP012).
\nNeste processo são permitidos as seguintes operações: Inserção, Atualização ou Remoção. Para inserir ou atualizar o registro o campo REMOVE_REGISTRO deverá ser nulo ou como N, sendo que quando o grupo já exisitir no Iniflex, o mesmo será atualizado. Para remover o registro, basta alterar o campo REMOVE_REGISTRO para S.
\nAs informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nPermite a criação de novos usuários para dentro do ERP. A senha deste usuário criado não poderá ser modificada através da API por questão de segurança, sendo assim, para o primeiro cadastro o sistema assumirá como senha, o próprio login, até que seja revisado diretamente no ERP.
\nOs dados inseridos serão destinados ao cadastro de ususario (PADM004).
\nSão permitidos as operações de inserção, e atualização, respeitando as seguintes regras:
o registro será inserido, porém caso o login seja identificado no ERP, os dados serão atualizados.
As informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nNeste endpoint são cadastrado os tipos de perdas.
\nOs dados inseridos serão destinados ao cadastro de tipos de perda (PPCP011).
\nSão permitidos as operações de inserção, e atualização, respeitando as seguintes regras:
o registro será inserido, porém caso o codigo junto a empresa, seja identificado no ERP, os dados serão atualizados.
As informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nNeste endpoint são cadastrado os Grupos dos Tipos de perdas.
\nOs dados inseridos serão destinados ao cadastro grupos de tipos de perda (PPCP010).
\nSão permitidos as operações de inserção, e atualização, respeitando as seguintes regras:
o registro será inserido, porém caso o codigo junto a empresa, seja identificado no ERP, os dados serão atualizados.
As informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\nAtenção: Este endpoint está depreciado, utilize a versão mais recente.
\nNeste endpoint são cadastrado os Itens e suas versões.
\nOs dados inseridos serão destinados ao cadastro de itens (PCAD020) e versões (PPCP017).
\nSão permitidos as operações de inserção, e atualização, respeitando as seguintes regras:
o registro será inserido, porém caso o codigo junto a empresa, seja identificado no ERP, os dados serão atualizados.
As informações no campo \"json\" devem ser enviados em modo string, sendo seu conteúdo, o body dos dados.
\nTodos os retornos são com status 200, sendo assim para diferenciar de erros de negócio, serão retornados alguns prefixos para identificação da mensagens:
\n