Mudanças entre as edições de "Discussão:Estoque Reservado"
(→Integração: Algumas correções ortográficas) |
|||
| (7 revisões intermediárias por 3 usuários não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
== Desenvolvimento == | == Desenvolvimento == | ||
| − | + | # Será necessário criar um novo identificador de Json para enviar pedidos orçados. Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json. | |
| − | # Será necessário criar um novo | ||
# Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração. Esse parâmetro será configurado com a quantidade de dias corridos para definir quando o pedido poderá ser cancelado, após a emissão do pedido. | # Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração. Esse parâmetro será configurado com a quantidade de dias corridos para definir quando o pedido poderá ser cancelado, após a emissão do pedido. | ||
== Integração == | == Integração == | ||
| − | # Será necessário criar um campo no ERP para informar se o pedido possui a situação orçada ou não. Essa tratativa tem como ação evitar pedidos duplicados no ERP; | + | # Será necessário criar um campo no ERP para informar se o pedido possui a situação orçada ou não. Essa tratativa tem como ação evitar pedidos duplicados no ERP (Essa é uma trativa que o Jardel solicitou que fosse colocada no documento, pois ele precisa garatir que o pedido não integre duas vezes no ERP); |
# Será necessário identificar se o pedido teve alteração ou não. Dessa forma evitamos que o pedido seja enviado várias vezes ao ERP; | # Será necessário identificar se o pedido teve alteração ou não. Dessa forma evitamos que o pedido seja enviado várias vezes ao ERP; | ||
# Será necessário adequar o fonte para pegar o novo arquivo Json; | # Será necessário adequar o fonte para pegar o novo arquivo Json; | ||
# Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados; | # Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados; | ||
# Os pedidos orçados não deverão retornar nas tabelas pedido_retorno e item_pedido_retorno; | # Os pedidos orçados não deverão retornar nas tabelas pedido_retorno e item_pedido_retorno; | ||
| − | # Será necessário salvar na ack a falha ou sucesso da exportação dos pedidos orçados | + | # Será necessário informar através da ack se a exportação de pedidos orçados foi realizada com sucesso ou falha. |
| + | |||
| + | == Questionamentos == | ||
| + | |||
| + | ==== Desenvolvimento ==== | ||
| + | |||
| + | <blockquote>será necessário criar uma nova descrição na NM_TABLE na tabela ACK_TABELA_PROCEDURE</blockquote> | ||
| + | |||
| + | Em relação a o que é dito na tratativa do ACK, qual a tratativa que será feita com o ACK do orçamento enviado? | ||
| + | |||
| + | Digo isso porque o comportamento padrão é salvar para futura disponibilização os sucessos e erros. Tratativas especiais são feitas sob demanda; por exemplo, a tratativa do pedido é atualizar a data de exportação caso tenha sido enviada com sucesso. Assim, qual a necessidade dessa tratativa? | ||
| + | |||
| + | Então não vejo o porquê de ter algo desse tipo. | ||
| + | |||
| + | <blockquote>Será necessária criar um novo modelo de Json [...]</blockquote> | ||
| + | |||
| + | Tenho a impressão de que não era essa a intenção... O modelo será o mesmo do pedido, com um identificador distinto. | ||
| + | |||
| + | <blockquote>[...] Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json</blockquote> | ||
| + | |||
| + | Melhor separar em '''extração''' de dados essa questão. | ||
| + | |||
| + | <blockquote>Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração</blockquote> | ||
| + | |||
| + | Já há algo nesse sentido no Erp-Importer. No rodapé da documentação pública do Erp-Importer temos o seguinte dito: | ||
| + | |||
| + | <blockquote>Ainda existem os end-points <code>{host/contexto}/{tenant}/data/{tabela}/{chave}</code> e <code>{host/contexto}/{tenant}/import-new</code>, serão documentados posteriormente.</blockquote> | ||
| + | |||
| + | No caso, o end-point específico <code>{host/contexto}/{tenant}/data/{tabela}/{chave}</code> permite resgatar/alterar/deletar coisas da chave específica. Só foi implementado coisas relativas a tabelas de chave única (como é o caso de pedido). Detalhes do como fazer isso posso fornecer depois. O Protheus tem suporte aos detalhes necessários para fazer essa atualização específica. | ||
| + | |||
| + | Será feita a atualização na documentação em https://softsite.gitlab.io/tj2/erp-importer para falar especificamente sobre esse end-point e suas capacidades. | ||
| + | |||
| + | ==== Integração ==== | ||
| + | |||
| + | <blockquote>Será necessário adequar o fonte para pegar o novo arquivo Json</blockquote> | ||
| + | |||
| + | Será um novo consumo de serviço. Talvez nem tanto "adequar" um fonte pré-existente, talvez criar um novo. Não gosto de entrar tanto no mérito do '''como''' será feito, apenas o que espero do '''resultado final'''. Enfim, só um detalhe de comunicação | ||
| + | |||
| + | <blockquote>Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados</blockquote> | ||
| + | |||
| + | Aqui, novamente, conforme conversamos, indo para o ponto em que a nomenclatura é correta. É responsabilidade do ''cliente'' fornecer qual foi a última data ''através'' da URL. Detalhes precisos do como é feita essa informação será adicionada na documentação do erp-importer https://softsite.gitlab.io/tj2/erp-importer. | ||
| + | |||
| + | Esse dado será disponibilizado através da "tabela" de nome <code>VALIDADE_TJ</code>. Essa "tabela" conterá uma única linha com uma única coluna. Mais detalhes serão especificados em https://softsite.gitlab.io/tj2/protocolo-tj, assim como será mencionado adequadamente aqui https://softsite.gitlab.io/tj2/erp-integrator. | ||
| + | |||
| + | |||
| + | <blockquote>Será necessário salvar na ack a falha ou sucesso da exportação dos pedidos orçados</blockquote> | ||
| + | |||
| + | No caso, não deveria estar descrito "será necessário informar através do ACK se os orçamentos foram enviados com sucesso ou não"? | ||
Edição atual tal como às 19h40min de 7 de outubro de 2020
Desenvolvimento
- Será necessário criar um novo identificador de Json para enviar pedidos orçados. Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json.
- Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração. Esse parâmetro será configurado com a quantidade de dias corridos para definir quando o pedido poderá ser cancelado, após a emissão do pedido.
Integração
- Será necessário criar um campo no ERP para informar se o pedido possui a situação orçada ou não. Essa tratativa tem como ação evitar pedidos duplicados no ERP (Essa é uma trativa que o Jardel solicitou que fosse colocada no documento, pois ele precisa garatir que o pedido não integre duas vezes no ERP);
- Será necessário identificar se o pedido teve alteração ou não. Dessa forma evitamos que o pedido seja enviado várias vezes ao ERP;
- Será necessário adequar o fonte para pegar o novo arquivo Json;
- Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados;
- Os pedidos orçados não deverão retornar nas tabelas pedido_retorno e item_pedido_retorno;
- Será necessário informar através da ack se a exportação de pedidos orçados foi realizada com sucesso ou falha.
Questionamentos
Desenvolvimento
será necessário criar uma nova descrição na NM_TABLE na tabela ACK_TABELA_PROCEDURE
Em relação a o que é dito na tratativa do ACK, qual a tratativa que será feita com o ACK do orçamento enviado?
Digo isso porque o comportamento padrão é salvar para futura disponibilização os sucessos e erros. Tratativas especiais são feitas sob demanda; por exemplo, a tratativa do pedido é atualizar a data de exportação caso tenha sido enviada com sucesso. Assim, qual a necessidade dessa tratativa?
Então não vejo o porquê de ter algo desse tipo.
Será necessária criar um novo modelo de Json [...]
Tenho a impressão de que não era essa a intenção... O modelo será o mesmo do pedido, com um identificador distinto.
[...] Vale salientar que pedidos com o status cancelado ou com a situação efetivada não deverão estar presente nesse Json
Melhor separar em extração de dados essa questão.
Será necessário criar um serviço para cancelamento de pedidos que funcionará em conjunto com uma configuração
Já há algo nesse sentido no Erp-Importer. No rodapé da documentação pública do Erp-Importer temos o seguinte dito:
Ainda existem os end-points
{host/contexto}/{tenant}/data/{tabela}/{chave}e{host/contexto}/{tenant}/import-new, serão documentados posteriormente.
No caso, o end-point específico {host/contexto}/{tenant}/data/{tabela}/{chave} permite resgatar/alterar/deletar coisas da chave específica. Só foi implementado coisas relativas a tabelas de chave única (como é o caso de pedido). Detalhes do como fazer isso posso fornecer depois. O Protheus tem suporte aos detalhes necessários para fazer essa atualização específica.
Será feita a atualização na documentação em https://softsite.gitlab.io/tj2/erp-importer para falar especificamente sobre esse end-point e suas capacidades.
Integração
Será necessário adequar o fonte para pegar o novo arquivo Json
Será um novo consumo de serviço. Talvez nem tanto "adequar" um fonte pré-existente, talvez criar um novo. Não gosto de entrar tanto no mérito do como será feito, apenas o que espero do resultado final. Enfim, só um detalhe de comunicação
Será necessário retornar na URL a última data de validade do TJ dos pedidos orçados
Aqui, novamente, conforme conversamos, indo para o ponto em que a nomenclatura é correta. É responsabilidade do cliente fornecer qual foi a última data através da URL. Detalhes precisos do como é feita essa informação será adicionada na documentação do erp-importer https://softsite.gitlab.io/tj2/erp-importer.
Esse dado será disponibilizado através da "tabela" de nome VALIDADE_TJ. Essa "tabela" conterá uma única linha com uma única coluna. Mais detalhes serão especificados em https://softsite.gitlab.io/tj2/protocolo-tj, assim como será mencionado adequadamente aqui https://softsite.gitlab.io/tj2/erp-integrator.
Será necessário salvar na ack a falha ou sucesso da exportação dos pedidos orçados
No caso, não deveria estar descrito "será necessário informar através do ACK se os orçamentos foram enviados com sucesso ou não"?