Q&A Api

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.

Customer

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.

Product

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

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 most of the cases this should be set to Normal.

Q: Most of the products sold by my company 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 ERP 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 ERP 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.

Purchase

Q: Are purchase orders received in Bitlog? How does ERP 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.

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: Price is optional.

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: In most of the cases this should be set to Open.

Sales

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 salesperson in my company wishes for the order to be only partially shipped. If we split the order into two shipments in ERP, 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.

Table

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.

Terms

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 going to the integration with ta-system.

Transaction

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)