Upload processes

Order transactions and inventory transactions share the same basic process for uploads according to the following rules:

 

External system

 

Interface Transactions

  • MMIHED - Received Header (MMS850)
  • MMIIDE - Received Identities (MMS851)
  • MMIINS - Received Instructions (MMS852)

M3 Interface

Order Transactions

  • MHIHED - Received Header (MHS850)
  • MHIPAC - Received Packages (MHS851)
  • MHILIN - Received Lines (MHS852)

Inventory 'Engine' MMS870 selects function based on Message Qualifier (MMS860)

Interface 'Engine'

Order 'Engine' MHS870 selects function based on Message Qualifier (MHS860)

  • MMMNGTRA - Actual Stock
  • MMMNGMOV - Move Balance ID's
  • MMMNGRCL - Reclassification

Business Function

  • PMS050BE - MO Receipts
  • MMUPDREP - Report Issues
  • PPS300BE - Goods Receipt
  • PPS310BE - QI Inspection
  • MMMNGGRC - DO/RO Receipts
  • MHMNGRET - Customer Order Returns

Supported upload transactions

The following M3 transaction types are supported by this interface for upload to M3.

How to execute the upload batch programs

The solution for executing the upload batch programs (MHS870/MMS870) is either event-driven or automatic using an auto job. The logic is based on the system or programs writing into M3 executing the batch job after a message, or several messages, are written to the intermediate files. The execution can be done in several ways, as follows:

Another option is to use a job scheduler or to create auto jobs.

Physical inventory for stores

The new transaction AddPartialCount has been added to MMS850MI. This development item enables reporting of partial counts for a physical inventory line in MMS301 in M3 BE using an external system, mainly hand-held devices like scanners.

The transaction AddPartialCount in MMS850MI supports reporting of partial counts for a specific line of a physical inventory request based on the physical inventory number (STNB), together with either the physical inventory line number (STRN), or the complete balance identity of such a line. Either item number or alias of category 2 can be used for addressing the balance identity.

The transaction can also be used for creating new inventory lines for a specific request. This is done by entering a balance identity which does not already exist on the list.

Furthermore, if an item exists in the item master file (MITMAS) and not in the specific warehouse for which the physical inventory is done, this item will automatically be added to the warehouse (MITBAL) and facility (MITFAC) when the transaction is processed.

An equivalent SndPartialCount transaction has also been created in MMS850MI to enable creation of the same kind of transactions, but without having them validated before they are actually processed. This can be useful for instance when the communication between the external system and M3 BE is not synchronous, or when a huge amount of data is being uploaded to M3BE at once or when data must not be lost because of evaluation errors.

The new functionality to partially count single physical inventory lines has changed the way that an external system needs to read physical inventory requests. When partial count is performed an external system might need to read the same physical inventory request several times, as well as read a physical inventory request for which reporting already has started. In order to address this new need a new transaction, LstStockTakeAll, has been added to MMS301MI as a complement to the original LstStockTake-transaction in MMS301MI which only read requests of status 40.

The new transaction, LstStockTakeAll, differs from LstStockTake in the following ways:

  1. Changed read function: The current LstStockTake-transaction only reads physical inventory headers of status 40. The new transaction reads all requests in the interval greater equal status 40 to lower than status 60, including status 41 and 51. When using the new transaction, the external system must decide which status that should be acknowledged.

  2. Changed update function: The current LstStockTake-transaction sets a read physical inventory header to status 41, the new transaction sets a physical inventory header to 41 if it before the read had status 40, and 51 if it before had status 50.

  3. In addition to the new LstStockTakeAll-transaction Related option 21 'Change status' in MMS300 has also been changed in order to reflect the functionality of the new List transaction. Before, this related option set a physical inventory header of status 41 back to 40. Now it also sets a header in status 51 back to 50.

For more information about the workflows, see Net Change Report 2481.

Received transactions - MHS850MI

Order transactions from the external system are recorded in M3 using MHS850MI. MHS850MI populates the following tables:

MHS850MI contains several transactions that can be used to send data. There are two types of transactions, generic transactions and custom transactions. The generic transactions can be used for any qualifier and correspond to the actual upload tables (See AddWhsHead, AddWhsPack and AddWhsLine). They are flexible but more complex and might require unnecessary overhead, depending on what the user wants to achieve. The message must be structured with one AddWhsHead-message, one or several AddWhsPack-messages, and one or several AddWhsLine-messages. The custom transactions are more streamlined and the three level structures are structured automatically from one MI transaction. An example is AddCOPick where a customer order pick line is reported. The message header, package, and line are generated from this single transaction.

MHS850/851/852 can be used to display and execute messages as well as to correct invalid or incorrect data. These programs are mainly designed for testing and monitoring purposes.

Order transactions can include actions taken for customer order picks, customer order returns, DO/RO picks and receipts, manufacturing order picks and receipts, purchase order receipts, and purchase quality inspection.

MHS850 has two additional action codes. 25 (Validate) will validate that the message contains correct information, but no 'business logic' validations will take place. This option corresponds to leaving the field 'Process flag' blank in MHS850MI. Action 21 (Execute) will 'post' that message to M3. This corresponds to Process Flag *EXE.

F14=Execute can be used to display MHS853. This program allows for filters to be specified on what messages to process.

F15=Validate can be also used to display MHS853. In this situation, only validation will occur - no execution of any messages.

One more method is available to process the messages. MHS853BE can be called in a batch function, or used with a Job Scheduler. This program takes partner, warehouse, and message types as parameters.

Backorders when a picking list is reported from an external system

It can be challenging to define how to manage backorders when a picking list is reported from an external system or partner.

In the API transactions to report a pick line, three parameters are important when managing backorders:

What should happen to a delivery line after it is reported when a shortage has occurred?

The main rule is that the M3 core logic should decide whenever the pick shortage should be backordered or not. Then the 'flagged as completed' parameter should always be set to zero and a deviation acceptance limit is defined in the program 'Item. Connect Order Line Completion Limit' (MMS425). However, if backorders are not used the parameter should be set to 1.

To manage partial reporting of a pick line, a good rule is to always set both the allocated and delivered quantity as the picked quantity.

See the example in the following figure to understand the different outcomes of a reporting transaction.

Back order handling at pick reporting - standard scenario

A pick line of ten pieces is downloaded to an external system. If partial reporting of four pieces is done, both the allocated and delivered quantity should be set to four. The result is a partial reported line in status 46 with six pieces left on the picking list.

If the allocated quantity is set to ten and the 'Flagged as completed' parameter is zero, M3 will decide if the pick line should be closed or backordered. If no acceptance limit is set, the line will be backordered.

If the allocated quantity is set to ten and the 'flagged as completed' parameter is one, the pick line will be closed and the status will be 69.

Move a picking list line to a packing or docking location

Partial movements to a packing or docking location are determined by the dispatch policy (MWS010). If parameter 460 (Move in partial move) is selected, you can report part of the picking list line to the packing or docking location. If it is not selected, the remaining quantity will be considered as a backorder quantity.

The issue/move mode in the transaction must be set to 1 for movement to a packing location and set to 2 for movement to a docking location. The default packing or docking location in MMS002 is used unless a specific To location is entered.

Stock messages - MMS850MI

Stock messages from the external system are recorded in M3 by MMS850MI. MMS850MI populates the following tables:

How the message is structured does not matter as long as the following rules are obeyed:

MMS850MI contains several transactions that can be used to send data. There are two types of transactions, generic transactions and custom transactions. The generic transactions can be used for any qualifier and correspond to the actual upload tables (See AddStkHead, AddStkId and AddStkIns). They are flexible but more complex and might require unnecessary overhead, depending on what the user wants to achieve. The message must be structured with one AddWhsHead-message, one or several AddWhsPack-messages, and one or several AddWhsLine-messages. The custom transactions are more streamlined and the three-level structure is created automatically from one MI transaction. An example is AddMove, where a stock movement is reported. The message header, identity, and instruction are generated from this single transaction.

MMS850/851/852 can be used to display and execute messages as well as to correct errors in the messages. These programs are mainly designed for testing and monitoring purposes.

Stock messages can include inventory adjustments, movements, and reclassifications.

Like MHS850, MMS850 has two additional action codes. 25=Validate will validate that the message contains correct information. Action 21=Execute will 'post' that message to M3.

F14=Execute can be used to display MMS853. This program allows for filters to be specified on which messages to process. If no filters are used, all messages will be processed.

F15=Validate can also be used to display MMS853. In this case, only validation will occur - no execution of any messages.

One more method is available to process the messages. MHS853BE can be called in a batch function, or used with a Job Scheduler. This program takes partner, warehouse, and message types as parameters.

Related topics