Produto: | Datasul |
Ocorrência: | Documentação de API |
| Nome Físico | sfc/sfapi010 |
Efetuar o Reporte (Apontamento) das Paradas do Centro de Trabalho.
Esta API pode ser utilizada de duas formas diferentes:
A sintaxe para a execução na modalidade Direta (“não-persistente”) da API é a seguinte:
run sfc/sfapi009.p (input <versao-integracao>,
input table tt-import-rep-parada,
output table tt-erro).
Parâmetros | Descrição |
<versao-integracao> | Para os clientes que possuem o EMS 2.04, deve ser informado o valor 204. Para os clientes com EMS 2.05 ou superior, deve ser informado o valor 205. |
tt-import-rep-parada | Temp-table com os dados a reportar. Pode ser passada para a API contendo um ou mais registros, sendo que cada registro representa uma Parada a reportar. Mais detalhes sobre a definição da temp-table, obrigatoriedade de campos, etc., estão descritos adiante. |
tt-erro | Temp-table de retorno de erros gerados na execução. |
A sintaxe para a execução na modalidade Persistente da API é a seguinte:
run sfc/sfapi009.p persistent set h-handle (input <versao-integracao>,
input table tt-import-rep-parada,
output table tt-erro).
Parâmetros | Descrição |
<versao-integracao> | Para os clientes que possuem o EMS 2.04, deve ser informado o valor 204. Para os clientes com EMS 2.05 ou superior, deve ser informado o valor 205. |
tt-import-rep-parada | Deverá ser passada como parâmetro vazia na inicialização. |
tt-erro | Temp-table de retorno de erros gerados na execução. |
Os parâmetros de entrada e saída são idênticos nas duas formas de execução (persistente e não-persistente). A diferença básica é que, na execução persistente, a efetivação do Reporte de Parada se dará mediante a execução do método pi-inicializa, o qual permite informar alguns parâmetros adicionais referentes à integração da Parada do Chão de Fábrica com o módulo de Manutenção Industrial. O método pi-inicializa é explicado adiante.
Importante: Na execução persistente, após a utilização dos métodos da API, é necessário e obrigatório efetuar a execução do método finalizaAPI, que é descrito mais adiante.
A API pode executar quatro diferentes tipos de transações básicas relacionadas ao Reporte de Paradas:
- Inclusão de reporte de parada;
- Iniciação de reporte de parada;
- Eliminação de reporte de parada;
- Finalização de reporte de parada já iniciado.
Quando é feita a inclusão de reporte de parada, a API necessita das seguintes informações:
- Tipo do reporte (deve ser igual a 1);
- Código do Centro de Trabalho;
- Código da Parada;
- Data de início da parada;
- Hora de início da parada;
- Data fim da parada;
- Hora fim da parada;
- Código da equipe, caso o centro de trabalho reporte pela equipe;
- Código do operador, caso o centro de trabalho reporte pelo operador.
As informações referentes às Datas e Horas da parada podem ser omitidas. Neste caso, a API irá completá-las automaticamente, da seguinte forma: se for omitida a data de início da parada, a API irá atribuir a ela a data de hoje e a hora atual. Caso não seja informada a data final, a API irá calculá-la baseando-se na data e hora de início, considerando a duração fixa de 1 (uma) hora.
Quando é feita a inicialização de uma parada no centro de trabalho a API necessita das seguintes informações:
- Tipo do reporte (deve ser igual a 2);
- Código do Centro de Trabalho;
- Código da Parada;
- Data de início da parada;
- Hora de início da parada;
- Código da equipe, caso o centro de trabalho reporte pela equipe;
- Código do operador, caso o centro de trabalho reporte pelo operador.
Da mesma forma que na inclusão da parada, é possível omitir a data e hora de início. Neste caso, a API irá atribuir a data de hoje e a hora atual.
Quando for feita a finalização de uma parada no centro de trabalho, a API irá procurar a primeiro reporte de parada iniciado do centro de trabalho e então irá finalizá-lo. Para isso a API necessita das seguintes informações:
- Tipo do reporte (deve ser igual a 3);
- Código do Centro de Trabalho;
- Data de término parada
- Hora de término da parada
Caso não seja informada a data e a hora de término do reporte, o programa irá calculá-la baseado na data e hora inicial considerando a duração fixa de 1 (uma) hora.
Quando é feita a eliminação de um reporte de parada para o centro de trabalho, a API necessita das seguintes informações:
- Tipo de reporte (deve ser igual a 4);
- Código do Centro de Trabalho;
- Código da parada;
- Data de início da parada;
- Hora de inicio da parada.
Caso não seja informada a data e hora de início da parada, a API irá eliminar a última parada do Centro de Trabalho informado.
Adicionalmente, caso o usuário possua a função “Automação” implantada, a API disponibiliza a função de Re-análise do Motivo de Parada. Esta função está disponível através do método pi-re-analise-motivo-parada, que é explicado adiante.
Para comunicação com os métodos da API, as seguintes temp-tables são utilizadas:
Tabela Temporária | Descrição | Entrada/Saída | |
tt-import-rep-parada | Utilizada para a entrada dos dados a reportar. Cada registro passado por esta temp-table corresponde a uma transação que será efetuada, sendo que podem ser passados um ou mais registros. Sua definição está na include sfc/sfapi010.i | Entrada | |
Atributo | Tipo | Descrição | |
tipo-rep | integer | Tipo de transação: 1– Incluir; 2 – Iniciar; 3 – Finalizar; 4 – Eliminar. | |
cod-ctrab | character | Código do Centro de Trabalho | |
cod-parada | character | Código do Motivo de Parada | |
num-om-progda | integer | Número da Parada Programada, deve ser informado caso o reporte de parada que está sendo efetuado seja a concretização de uma parada programada previamente. | |
dat-inic-parada | date | Data de Início da Parada | |
hr-inic-parada | decimal | Hora de Início da Parada, em segundos. | |
dat-fim-parada | date | Data de Término da Parada | |
hr-fim-parada | decimal | Hora de Término da Parada, em segundos. | |
val-refer-inic-parada | decimal | Valor de referência do início da parada. Campo calculado internamente, não deve ser informado. | |
val-refer-fim-parada | decimal | Valor de referência do término da parada. Campo calculado internamente, não deve ser informado. | |
cod-equipe | character | Código da Equipe. Deve ser informado quando o Centro de Trabalho estiver parametrizado para reportar equipe | |
cod-operador | character | Código do Operador. Deve ser informado quando o Centro de Trabalho estiver parametrizado para reportar operador | |
linha | integer | Número que identifica o registro na temp-table. Utilizado para atribuir os erros gerados na tt-erro aos respectivos Reportes. Útil para quando se usa a API em um programa de importação de Reportes via arquivo de texto, neste caso a linha corresponderia à linha do registro no texto. (Informação não obrigatória) | |
erro | logical | Campo utilizado internamente pela API | |
Tabela Temporária | Descrição | Entrada/Saída | |
tt-erro | Utilizada como saída padrão dos erros gerados na execução da API. Sua definição está na include cdp/cd0666.i | Saída | |
Atributo | Tipo | Descrição | |
i-sequen | integer | Seqüência do erro | |
cd-erro | integer | Número do erro | |
mensagem | character | Texto da mensagem de erro | |
Tabela Temporária | Descrição | Entrada/Saída | ||
rowErrors | Utilizada como saída alternativa dos erros gerados na execução da API. Sua definição encontra-se na include method/dbotterr.i. Obs.: Somente pode ser utilizada a rowErrors para saída dos erros da API quando fazendo a execução no modo persistente, e mediante o ajuste de um parâmetro específico. Mais detalhes estão descritos no detalhamento do método setaGeraRowErrors. | Saída | ||
Atributo | Tipo | Descrição | ||
ErrorSequence | integer | Seqüência do erro | ||
ErrorNumber | integer | Número do erro | ||
ErrorDescription | char | Descrição do erro | ||
ErrorParameters | char | Parâmetros passados para criar mensagem | ||
ErrorType | char | Tipo do erro. WARNING: Aviso; ERROR: Erro | ||
ErrorHelp | char | Texto de ajuda do erro | ||
ErrorSubType | char | Sub Tipo da mensagem de erro | ||
Para os clientes que possuem o EMS a partir da versão 2.07 (ou versões inferiores (a partir da versão 2.04), com a função “Automação” implantada), é possível a execução da API de Reporte de Paradas na modalidade “Persistente”, disponibilizando, assim, alguns parâmetros adicionais de integração com Manutenção Industrial.
Desta forma, seguem as instruções para utilização dos métodos disponíveis.
Requisito | Nenhum | |
Sintaxe | run pi-inicializa in h-handle (input <logical-on-line>, input <logical-usa-param>, input <logical-emite-ss>, input <logical-envia-email>, input <logical-cria-pend>, input <integer-nr-ord-produ>, input table tt-import-rep-parada, output table tt-erro). | |
Descrição | Efetua a transação (inclusão, exclusão, início ou término) de um ou mais reportes de parada. Obs.: Os cinco primeiros parâmetros da API somente têm efeito caso o cliente possua o módulo de Manutenção Industrial implantado. | |
| Parâmetros | Descrição |
| <logical-on-line> | Quando marcado como Yes, este parâmetro indica que a API poderá chamar, conforme outros parâmetros explicados a seguir, telas para a geração de Solicitação de Serviço ou envio de E-mail para o planejador. |
| <logical-usa-param> | Indica, quando marcado igual Yes, que irá utilizar os parâmetros <logical-envia-email> e <logical-emite-ss> para definir se irá ou não enviar e-mail para o planejador e emitir SS na Inclusão de um Reporte de Parada. Caso o parâmetro seja igual No, então serão consideradas os parâmetros de envio de e-mail e emissão de SS presentes no motivo de Parada informado. |
| <logical-emite-ss> | Indica que, na inclusão ou início de um Reporte de Parada, a API irá emitir uma Solicitação de Serviço no módulo de Manutenção Industrial. Este parâmetro somente terá efeito caso o parâmetro <logical-usa-param> esteja marcado igual à Yes. Caso contrário, será utilizado o parâmetro de emissão de SS presente no motivo de Parada. |
| <logical-envia-email> | Indica que, na inclusão ou início de um Reporte de Parada, a API irá enviar um e-mail para o planejador do Equipamento, cadastrado na Manutenção Industrial. Este parâmetro somente terá efeito caso o parâmetro <logical-usa-param> esteja marcado igual à Yes. Caso contrário, será utilizado o parâmetro de emissão de e-mail presente no motivo de Parada. |
| <logical-cria-pend> | Indica que, na ocorrência de erros na execução da API, será também gerada pendência de Importação. Observação: este parâmetro somente é utilizado para clientes que possuem o EMS na versão 2.05 ou superior. |
| <integer-nr-ord-produ> | Recebe o número da Ordem de Manutenção que deu origem à Parada que está sendo Incluída, Iniciada ou Finalizada. Caso não haja ordem de manutenção, deve ser passado o valor 0 (zero) neste parâmetro. |
| tt-import-rep-parada | Recebe a temp-table populada com os registros relativos aos reportes de parada que serão efetivados. Quando executando persistente e on-line, é indicado enviar apenas um registro por vez, já que poderão ser apresentadas ao usuário telas para manipular as SSs e e-mails enviados em função da parada. É importante observar também que, caso seja informada uma ordem de manutenção no parâmetro <integer-nr-ord-produ>, a mesma será atribuída a todos os registros de Parada, caso haja mais de um na temp-table. |
| tt-erro | Temp-table que retorna eventuais erros ocorridos na gravação das informações. |
Retorno | Não há. | |
Requisito | Nenhum |
Sintaxe | run setaGeraRowErrors in h-handle. |
Descrição | Quando executada antes da chamada de qualquer outro método, indica que a API deverá gerar os erros na temp-table rowErrors, em paralelo à temp-table de erros padrão (tt-erro). Esta opção é útil quando se está chamando a API a partir de uma interface escrita com thinTemplates, a qual tem como temp-table padrão de erros a rowErrors. |
Retorno | Não há. |
Requisito | Ter executado outro método que possa ter gerado erros em sua execução. Ter executado o método setaGeraRowErrors no início da execução da API. | |
Sintaxe | run retornaRowErrors in h-handle (output table rowErrors). | |
Descrição | Retorna a temp-table rowErrors populada com os erros gerados na execução. | |
| Parâmetros | Descrição |
| rowErrors | Retorna esta temp-table populada com os erros. |
Retorno | Não há. | |
Requisito | Possuir uma parada Iniciada ou Incluída (Iniciada e finalizada) que se necessite reanalisar. |
Sintaxe | run pi-re-analise-parada in h-handle(input <rowid-rep-parada-ctrab>, input <character-cod-parada>, input <date-data-fim-prevista>, input <integer-hra-fim-prevista>, input <integer-nr-ord-produ>). |
Descrição | A função Re-análise de Parada tem como objetivo permitir que uma parada tenha seu motivo e ordem de manutenção modificados após sua Inclusão ou Início. No caso de paradas Iniciadas, também é possível, através desta função, a alteração da data/hora prevista de término. Essa reclassificação da parada impacta nas estatísticas de parada e no processo de alocação de atividades do módulo Chão de Fábrica. |
| Parâmetros | Descrição | |
| <rowid-rep-parada-ctrab> | Rowid do registro da tabela rep-parada-ctrab cuja parada se deseja Reanalisar. | |
| <character-cod-parada> | Código do novo motivo de parada que se deseja informar. | |
| <date-data-fim-prevista> | Indica a nova data de fim prevista para a parada. Somente será considerado este parâmetro quando se tratar de Parada Iniciada (não finalizada). | |
| <integer-hra-fim-prevista> | Indica a nova hora de fim prevista para a parada, devendo ser informadoem segundos. Somenteserá considerado este parâmetro quando se tratar de Parada Iniciada (não finalizada). | |
| <integer-nr-ord-produ> | Permite informar a Ordem de Manutenção que deu origem a Parada, ou modificar uma ordem informada anteriormente. Caso não haja ordem de manutenção, deve ser passado o valor 0 (zero) neste parâmetro. | |
Retorno | Quando ocorrem erros durante as validações das informações, a API retorna o valor NOK. Por este motivo, o programa chamador deverá ter tratamento para, após a execução deste método, retornar os erros caso haja return-value = “NOK” através do método retornaRowErrors. | ||
Requisito | Nenhum |
Sintaxe | run finalizaAPI in h-handle. |
Descrição | Método que efetua a finalização da API, eliminando da memória todos os componentes por ela utilizada. Sua execução é obrigatória, devendo, ser executado após a utilização da API. |
Retorno | Não há. |
