K3S Application Integration

Sections in this article

K3S Hosted Applications

K3S hosts all its applications in its own secure private cloud servers. This spans two data centers located in separate in different national power grids to give the most secure and fault-tolerant setup available for inventory management applications.

Components Of K3S Application

K3S has strict data standards for all its applications. While K3S applications themselves are very flexible in what kinds of data they can consume and what abilities they allow, the transmission of data itself must adhere to our standards listed below. There are eight main components for consideration to integrate to a K3S Application:

1. Site-to-site Tunnel Connection For Users

K3S will be utilizing site-to-site VPN tunnels with port limited access for all connections to our applications. All access for your company will come through this tunnel and no individual user access to login to our VPN is allowed. There is no public facing access to any K3S application. This gives greater security to our application and allows your company to control access to what user has access to your K3S application.

There will be two end points for all site-to-site tunnel connections setup: Production and Disaster Recovery.

K3S will work with your IT director to setup these connections.

2. Data Exchange Via SFTP

K3S requires all customers to exchange data via SFTP. Customers can provide their own secure SFTP server (provided it follows the standards below) or utilize our service at k3s.files.com.

K3S requires chrooted individual accounts with 4 folders based off the chroot:

  • /diverter
  • /interface
  • /pos
  • /temporary

If K3S is providing the SFTP service, the user and password will be provided. If the customer is utilizing their own SFTP service, there will be a strict username that K3S must use to access. This will be provided in technical calls.

3. Initial Setup Files / Lists

There are three initial setup files / lists that will be used for the database: a list of Users, Buyer Groups, and Locations. These lists can be emailed to K3S for manual entry, or developed into a CSV file for easy import. K3S uses the pipe delimiter “|” in all CSV files. The format for the files is shown below:

List Of Users
  • User ID - 10 characters
  • User name - 25 characters
  • Default Buyer Group - 5 characters (typically buyer #)
  • Location ID - 5 characters
  • Manager - 1 character (has authority to change any information in K3S)

Example:

User ID      User name          Buy Group   Location     Manager (1=Yes, 0=No) 
KING3        King Harrison          01         01               0 
JOHNS        John Smith             02         01               1 
MARYJ        Mary Jones (Candy)     03         01               0 
SAM          Sam Fredrick           SAMFR      ATL              0 
List Of Buyer Groups
  • Buy Grouper - 5 characters (typically buyer #s or department #s)
  • Description - 35 characters (typically user’s name or department description)
  • User ID - 10 characters

Example:

Buy group     Description               User ID 
01            King Harrison             KING3 
02            John Smith                JOHNS 
03            Mary Jones (candy)        MARYJ 
04            Mary Jones (toys)         MARYJ 
SAMFR         Sam Fredrick              SAM 
List Of Locations
  • Location ID - 5 characters
  • Description - 40 characters
  • Region ID - 5 character

Example:

Location ID          Description           Region 
01                   Charlotte, NC           SOUTH 
ATL                  Atlanta, GA             SOUTH 
BUF                  Buffalo, NY             NORTH 

4. Development Of Main K3S Interface Files From ERP

K3S will work with your IT staff to help create the files needed for importing. These files will follow the naming convention below and will always carry the .csv prefix. There are five main files needed to create a K3S standard application integration:

Overall standards of files:

  • Files will include the header record in all files, even the K_READY file
  • All date fields will use *ISO format, CCYY-MM-DD
  • Empty dates should be sent as ‘0001-01-01’
  • POs will be called ‘PO’ + the PO number + .csv (Example: PO8500021.CSV, PO8500022.CSV)
  • Night interface files (K_READY.CSV, K_INTPROD.CSV, K_PRODLTM.CSV, K_INTSUPL.CSV, K_INTDALY.CSV) will not be removed once they are used by K3S. The customer will overwrite the file on the exchange site when they have a fresh file.
  • PO files (PO8500021.CSV, PO8500022.CSV, etc) should be removed by the customer from the exchange site once they are consumed by the customer.
  • The PO cross reference file (K_POXREF.CSV) will not be removed once used by K3S. The customer will overwrite the file on the exchange site when they have a fresh file.
  • The PO cross reference file (K_POXREF.CSV) should accumulate records throughout the day for all POs placed that day. Each day the customer will start with an empty file and add on records as POs are placed by the user.
  • Diverter files (K_ALTSRC01.CSV, K_ALTSRC02.CSV, etc) will be removed from the exchange site by K3S once they are consumed.

A K3S application would expect these files to be developed daily and use the decided upon SFTP server. As long as a supplier exists within a system that should be bought from and a product exists that will be purchased (even if the on hand is 0) every single supplier and product will have an entry in these files every day. The K_READY file is always the last one transmitted to signal the successful transmission of all the other files.

K3S will pull these files in CSV pipe delimited format (ie K_INTSUPL.csv, K_INTDALY.csv).

5. Shell Files With Sample Data & Notes File Download

Here is a zip of the four main files in Excel format with sample data that can act as a shell for setting up your data. Note that the format is in Excel for ease of use, but must be exported to pipe delimited “|” CSV:

Here is a zip of an Excel file we have formatted to easily take notes on the fields while working with K3S to map each field from our files to your files. This is not used for integration other than your reference:

6. Define Processes And Schedule

To deliver the data for processing a schedule must be set of when K3S can pick up the data. K3S will want to know when your company’s End Of Day (EOD) job is done processing to determine a reasonable time to pickup data.

For Example: If the EOD process normally ends ~3:20am, K3S will suggest going to pick up the formatted files at 4am to ensure they are available, even if the EOD process runs long. The verification that the file processing is complete is the K_READY file described above is created with today’s date. It is imperative that this file is created last and only upon successful creation of the other files.

7. PO Approval Process

K3S has a standard template for POs with an extensive list of available fields. This allows us to configure to any number of ERPs. From our generated suggested orders within our system, when the user clicks ‘Approve Order’ a PO file with a K3S PO Number will be created and sent via the same transfer process for the interface files. From there the customer’s ERP will consume the created PO (usually on a timed polling interval of ~5 minutes). If the K3S PO Number is not the designated PO Number to be used within an ERP, after consumption and adjustment, the ERP will send back a cross-reference file of the ERP PO Number and the K3S PO Number. K3S will then (again on a timed polling interval of ~5 minutes) update the PO within our system to have the corresponding desired PO Number. Each day we would expect the customer to clear our or delete the K_POXREF. Deleting this file as the last step before K_READY creation tends to work best.

NOTE For proper metrics to match with the ERP, K3S requires a PO Number to match the final ERP PO number.

8. Additional Files, Configurations, and Post Processing

K3S is able to import and configure additional files into its Night Job process to add additional functionality or to automatically setup functions built into the system (ex: automatically setup deals or hold outs). We are also able to take additional data for presentation on the Your Space and Your Screen sections.

Examples of Additional K3S Interface Files:

The rules for developing these files vary per account.

K3S will pull these files in CSV pipe delimited format (ie INTSDIS, INTPLVL).

K3S also has the ability to do post processing business specific rules on data that we ship back to your ERP. An example is that in ReStore often the results from the Night Job are directly sent back to the ERP for use. We are able to apply business rules to this data before it is sent back and consumed.

Because of the way Replenish and ReStore were developed they are very flexible applications to suit most needs for inventory management and procurement. Discuss these additional options with a K3S Engineer to learn what is possible.