Histórico da Página

...

Registers: The Entry Point PCPXFUNPPI  enables to inhibit the integration in certain routine. Example: If you do not want integration to occur in the creation of MATA650 orders, you can use this function to inhibit the use. Details in: PCPXFUNPPI_Routines_not_executing_integration_with_the_PC_Factory.

Register of Item: o Ponto de entrada PCPADDTAGS permite incluir tags específicas nas mensagens padrões TOTVS. Está habilitado para o cadastro de item MATA010. Detalhes emThe Entry Point PCPADDTAGS enables to add specific tags in TOTVS standard messages. It is enabled for the registration of the item MATA010. Details in: PCPADDTAGS_AdicionarAdd_informacoesinformation_XML_integracaointegration_TOTVS_MES.Cadastro de Processos: o Ponto de entrada PCPADDTAGS permite incluir tags específicas nas mensagens padrões TOTVS. Está habilitado para o cadastro de roteiro MATA632. Detalhes em

Register of Processes: The Entry Point PCPADDTAGS enables to add specific tags in TOTVS standar messages. It is enabled for the registration of script MATA632. Details in: PCPADDTAGS_AdicionarAdd_informacoesinformation_XML_integracaointegration_TOTVS_MES

Internal Movements. The entry points MATI250CRG and MATI240CRG enable specific validation. These validations are under the customers' responsibility, as each has its own rule. You cannot generate the values of fields that were generated by message. Details in:MATI240CRG_Add_information_Adapter_of_internal_movements and MATI250CRG_Add_information_Adapter_of_production_movements

Transfers: The entry point MI261RCV does not enable the execution of the integration. Details in: MI261RCV_Execute_integration_TransferWarehouseRecusa: O

ponto de entrada MATI685EXC permite verificar se a recusa será executado ou não. Este ponto de entrada é indicado para validações que impeçam o apontamento de recusa ou atualizações de informações necessárias para realizar a recusa. Detalhes em: MATI685EXC_Processa_Mensagem_RecusaRefusal: The Entry Point MATI685EXC enables to check whether the refusal is executed. This entry point is indicated for the validations hindering the annotation of refusal or updating of information necessary to execute the refusal. Details in: MATI685EXC_Processes_Message_Refusal

Execute in various branches

...

[WebServices]

PrepareIn=99,01

Control of latency

There are situations in which the webservice waiting time is lower than the time of processing of information to ERP. There may be situations in which the ERP continues to process the import and the WebService of PC-Factory stops waiting for the answer. When PC-Factory does not receive the answer in time, the same file is resent, generating then duplicity in the message processing.

Solution:

Control ID of PC-Factory for received messages. Every received message must be handled like this:

• ProductionAppointment
• StopReport
• MovementsInternal
• TransferWarehouse
• StopReason
• WasteReason

In the XML´s, the TAG  Key name = "IDPCfactory" is used.

<BusinessEvent>

      <Entity>Entity</Entity>

      <Event>upsert</Event>

      <Identification>

        <key name="IDPCFactory">29892829</key>

      </Identification>

</BusinessEvent>

The return with error displays a message with the following pattern:

<ProcessedOn>2017-03-28T09:11:17</ProcessedOn>

   <Status>ERROR</Status>

   <ListOfMessages>

      <Message type="ERROR" code="N">MENSAGEM</Message>

   </ListOfMessages>

</ProcessingInformation>

The return XML must follow this rule:

• When ID is processed and has ERROR

              Retorns the ID PC-Factory in tag  <UUID>

              In the tag Message type="ERROR" code="2", uses the 2 to indicate error.

              The message is: ID xxxx already processed. Status: error message”.

             Example: <Message type="ERROR" code="2">ID productionappointment-0038 already processed. Status: ProductionOrderNumber not registered in Protheus.</Message>

• When ID is already successfully processed

              Retorns the ID PC-Factory in the tag  <UUID>

              In the tag Message type="ERROR" code="3", uses the 3 to indicate the successfull processing.

             The message is: "ID xxxx already processed. Status: ID of Protheus" or  "ID xxxx already processed. Status: Reprocessed. ID of Protheus" when PC-Factory sends more than once.

             Example 1:      <Message type="ERROR" code="3">ID productionappointment-0038 already processed. Status: 5091</Message>

             Example 2:      <Message type="ERROR" code="3">ID productionappointment-0038 already processed. Status: Reprocessed. 5091</Message>.

• When ID already is in base but in processing

              Retorns the ID PC-Factory in the tag  <UUID>

              In the tag Message type="ERROR" code="4", uses the 4 to indicate that is in processing.

              The message is: ID xxxx is being processed by Protheus.

              Example: <Message type="ERROR" code="4">ID apapapapeaaa is being processed by Protheus.</Message>

Note:

The return, when message is processed "right away" , within the waiting time of the webservice, is "1" - Processed for the first time with ERROR or OK.

Example:

With Error:

<ProcessingInformation>

   <ProcessedOn>2017-03-28T09:00:03</ProcessedOn>

   <Status>ERROR</Status>

   <ListOfMessages>

      <Message type="ERROR" code="1">ProductionOrderNumber not registered in protheus.</Message>

   </ListOfMessages>

</ProcessingInformation>

Successfully:

<ProcessingInformation>

         <ProcessedOn>2017-03-28T08:57:28</ProcessedOn>

         <Status>OK</Status>

</ProcessingInformation>

<ReturnContent>

         <ListOfInternalId>

            <InternalId>

               <Name>PRODUCTIONAPPOINTMENTINTERNALID</Name>

               <Destination>5090</Destination>

            </InternalId>

         </ListOfInternalId>

</ReturnContent>

Unexpected situations may occur: the stoppage of Protheus service, downsizing of database, power outage, among others. If during the integration processing, the record of PC-Factory (ID of PC-Factory) may be locked up and there is no output of message from the processing queue. To handle this situation:

The PC-Factory tries to send by determination of time - time which is parameterized in PC-Factory. If you continue to receive the same message after the parameterized time, PC-Factory generates pendency of delivery and moves to the next record. Upon doing this, a counter of messages that were not sent is generated. When this counter reaches a (parameterized) limit, the integration process is stopped so the users can solve the problem. The processing control is registered in LOG SOH table.

Abaixo tabela dos códigos enviados:

Importante:

• Caso um registro fique preso com status de "registro em processamento", este poderá ser destravado pela rotina PCPA112, incluindo o IDMES correspondente.
• O reprocessamento de uma mensagem com ERRO(2) pode ser feito passando a tag Reprocess = true.
  Exemplo:

<BusinessEvent>

            <Entity>productionappointment</Entity>

            <Event>upsert</Event>

            <Identification>

              <key name="IDPCFactory">9o93049u88557</key>

              <key name="Reprocess">true</key>

            </Identification>

        </BusinessEvent>

Routines

Parameterization - PCPA109

...