General questions

Q: All entities seem to include a stamp field. Is this stable once an entity has been created, i.e. if we create a product with the code ABC123, then we update the product, will its stamp field stay the same? In other words, is this like your internal identifier for entities?
A: No it is not our internal identifier for entities. This is a timestamp field not an actual timestamp but a relative one within the database, where you don’t need to send in anything so every time that a row with a timestamp column is modified or inserted, the incremented database timestamp value is inserted in the timestamp column and updated. Think of stamp as a row version. But nothing you need to send it is just for internal use within the database.


Q: Do "customer categories" give us any benefits? For example, would it be worth our while to create categories for "individuals" and "businesses" and mark customers accordingly?
A: For example, if you have like different deliverynotes for different customercategories then we can use this to sort this kind of logic out. But it is not necessary for the system to work.


Q: What units do the dimensions length, width and height use? Millimeters due to being integers?
A: Millimeters works fine. As long as it is consistent on all products.

Q: What units do the weights netWeight and grossWeight use? Kilograms due to being doubles?
A: Kilograms works fine, as long as it is consistent

Q: What unit does the volume field use? Cubic meters due to being doubles?
A: Could be cubic meter or cubic centimeter but Cubicmeter are preferred (Patric: prefer cubic decimeters, or liters)

Q: Creating a new product is possible using the endpoint POST /product, and it accepts a barCode field. Will this be sufficient for specifying the GTIN of each product, or do we still need to use the endpoint POST /product/bar? In other words, is POST /product/bar only useful for adding more than one barcode per product?
A: Correct

Q: Is type a field that we should specify and what is it used for? It accepts an enum of: Normal, Intangible, Special, Structure.
A: In 95 % of the cases this should be set to Normal. I think you only will use normal. We can discuss the other types on the meeting. (For now, let's just go with "Normal" and figure out "Structure" and "Special" later if needed)

Q: Most of the products sold by FDS are individual pieces. Should we omit the unit field or create a new unit using POST /product/unit for e.g. pcs? Regarding units, can you give us details on the factor field?
A: Send in PCS. (No need to create units if not using factor)

Q: How useful are the fields supplier and brand? We have brand information per SKU in MiddleWare so in theory we could create the brands and include them if desired, but currently we have no supplier information apart from a supplier's product number (which may be empty).
A: Not mandatory with both and only use under productentity for creating reports with that kind of information. So brand can be NULL, SupplierCode on product mandatory? And if you use SupplieritemCode in Inbound (supplier is actually Supplier product code, which we do have and should send; brand can be omitted for now at least)

Q: The endpoint POST /product/balance can be used to update the stock balance of a product. Would this be useful in some cases or does Bitlog act as a master source for balances, since it's closest to the actual physical products? Our current WMS informs us of manual balance changes made by users, does Bitlog do this?
A: Yes bitlog will be the master of the balance all transaction regarding balance should be done in Bitlog WMS. This is just if you have any specific need for this integration to go bothways. But in general you do not post balance to Bitlog. Bitlog creates transactions for you to fetch when balance is changing in Bitlog.

Q: Is it possible for Bitlog operators to make changes to the dimensions or other information of a product that MiddleWare should read? Our current WMS fires an event for these kinds of changes, I believe it's mostly useful for fixing dimensions.
A: No. ERP should be master of productinformation.


Q: Are purchase orders received in Bitlog? How does MiddleWare get information on purchase order receivals? Current WMS sends an event upon receipt of purchase order, and the receipt includes which lines and how many quantities were received.
A: Yes, you will use the GET/api/transaction/sync for this part and as soon as item from purchase is received to stock we will create a transaction that you can fetch.

I assume the answers to the questions below also apply to sales orders.

Q: Is it alright for purchase order line prices to be negative? Looking at our current purchase orders there are quite a few negative lines.
A: I don't see any problem from a databaseperspective but why should it exists in first place? (Price is optional, don't send for purchase orders; need to discuss sales orders further)

Q: Should we send/update the status field of the purchase order or is that done by Bitlog? It takes in an enum of Unknown, Open, Cancelled, Received
A: [fill in answer]


Q: What is the complete field? Description: Complete shipment flag.
A: [If you don’t wish to deliver any items on the SalesOrder if some item is missing on the order then this should be True. You want to send the complete order or not send it at all so to say.

Q: What is the parent field used for in lines?
A: It is used for ItemStructures like If you are selling a product that is part/component of another product. So the person ordering the product on the website is for example buying a pool then in this pool there are amount of pieces/parts/components to be picked on order to the deliver this pool, I don’t know if you have that kind of products. We can discuss this.

Q: Is the method field for specifying delivery method useful?
A: Yes that is the shipment method, if the order is to be sent with DHL Service Point, Postnord Parcel, Schenker Parcel, Schenker Pallet and so on. So this you must send in. (First create methods using POST /delivery/method (with code and name), then send the code in the method field for sales orders)

Q: Assume that we send incoming orders in their entirety right after they are created. Then some FDS salesperson wishes for the order to be only partially shipped. If we split the order into two shipments in MiddleWare, can we edit the whole order in Bitlog to only include the items to be partially shipped and create a new order for the items to be sent later? Can this create problems if Bitlog has already reserved items for the earlier order that we now want to ship later?
A: As long as the order is waiting (not started in picking) this is no problem to do. But then I suggest that you always send in CompleteOrder = true then this would work as you describe. Think we need to discuss this so we understand eachother.

Q: How should we tell Bitlog/AutoStore which parcel types should be used for packing which products? MiddleWare has already calculated parcels for the shipment when the order was generated, and our understanding is that Bitlog should honor these parcels when packing the order.
A: Needs to be discussed, maybe send in a customfield with information that we later on can use when packing/confirming the pick. (It would be difficult to send parcels from MW; need to discuss this further)

Q: How does the "registration plate" attached to each picked parcel work? Can MiddleWare define what is printed to the registration plate or is that autogenerated by Bitlog and needs to be somehow associated to a parcel in MiddleWare, e.g. via webhook or transaction?
A: [fill in answer] Needs to be discussed (If packing is done in Bitlog, we don't need to care about this; pending a decision on this)

Q: After AutoStore picking, shipments are supposed to be packed by users via MiddleWare. How would MiddleWare inform Bitlog once the packing of a shipment is complete and the parcel is ready to be returned to the conveyor which takes it to the weighing station?
A: [fill in answer] This is yet to be decided whether middleware or Bitlog should do the packing. (Pending decision on where packing is done)

Q: After AutoStore packing a shipment goes to a weighing station. How do we get the weighing information to MiddleWare?
A: [fill in answer] Needs to be discussed (Pending decision on where packing is done)

Q: After weighing MiddleWare is supposed to create the shipping documents via Unifaun, then these should be printed and a robotic hand should attach them to the shipment. How do we print the documents and/or control the robotic hand?
A: [fill in answer] ] This is yet to be decided whether middleware or Bitlog should do the packing and send information to Unifaun. (Pending decision on where packing is done)

Q: Some shipping documents do not come from Unifaun but still go to the same conveyor with the weighing station and printer. How do we instruct Bitlog to ignore the weighing/printing of these parcels?
A: [fill in answer] Needs to be discussed (Pending decision on where packing is done)

Q: What are the differences in workflows between shipments with only one parcel vs. shipments with multiple parcels? What about a shipment with one parcel and one pallet?
A: [fill in answer] Needs to be discussed (Pending decision on where packing is done)


Q: Are any of these useful for us?
A: [fill in answer] No not as for now.


Q: Is this a way to specify what is allowed in the fields field of most (all?) models? I.e. if we want to add any additional information to those models using the fields attribute we would first need to define a new column for these types using POST /table/{id}/column where ID is e.g. sales?
A: Correct POST/api/table/{id}/column.
We can also manually creates this columns in the database to start with.

Q: Some GET endpoints such as GET /customer take in a parameter called query.expand (true or false). How does this affect the response of the query?
A: [fill in answer]


Q: Are either delivery or payment terms useful for us?
A: If that information should be used in bitlog in either reports or sending data, or grouping orders for deliverygroups then yes otherwise no. Deliveryterm can be needed depending on if we are gping to the integration with Unifaun or not. (Prefer automatic creation via API when needed)


Q: How should we use these and are there still upcoming developments to these regarding picking of sales orders, as per our conversation in a previous meeting?
A: First make a GET/api/transaction/sync and then make a PUT/api/transaction/sync/{id} to tell if the transaction was valid in ERP.

Q: Our current WMS supports the following events/transactions, does Bitlog support some/all of these? This is mostly to understand whether or not we can reuse the logic of how shipments are currently picked or if it differs significantly.

  • ArticleInfo when a user updates product information such as dimensions.

  • BalanceChange when a user performs manual inventory update for a stock item.

  • BalanceReport is generated once a day and includes stock balances for all items.

  • DeliveryAcknowledgement when users mark sales order lines as picked, may only include a subset of all lines.

  • Reception when a purchase order lines are confirmed as received, may only include a subset of all lines.

A: ArticleInfo - NO
BalanceChange - GET/api/transaction/sync, type of sync = Take (manually updated by users, for example due to mismatch between system and actual balance; is the quantity delta or absolute?) and Move (movement between warehouses)
BalanceReport - GET/api/product/balance
DeliveryAcknowledgement GET/api/transaction/sync, type of sync = Out
Reception - GET/api/transaction/sync type of sync = In
(Transactions are only used for balance updates, not for other data)