In order to do a complete refresh of the report, the user has to go through 4 successive operations:

• Click Retrieve.
• Click Upload.
• Wait! Don't forget, it's an important step.
• Click Download.

Somehow this design is really cumbersome, because those 4 operations are just mundane tasks aiming for a unique purpose: getting the latest version of the report.

Thus, we have decided to upgrade the application, by actually removing two buttons. Here is the latest screenshot of the application.

With this design, the user just has to click once on Refresh and LSSC will perform the 4 operations mentioned here above on its own (with a wait time set to 1h, which should be fine for most users).

Then, since all the user wants is an up-to-date report, the question becomes:
Can't we get rid of this last button? Well, sort of.

It seems difficult to actually get rid of this Refresh button, yet, what we can do is to schedule background refresh operations. Instead of getting rid of the Refresh button, we would get rid of the need to actually click it once an auto-refresh schedule has been setup.

Auto-refresh is part of our mid-term plans, stay tuned.

Compared to Lokad Desktop Sales Forecasting, LSSC comes as significant upgrade

• True business-oriented report that includes stocks on hand, suppliers, lead times, service levels ... in addition to the raw sales forecasts.
• Incremental inventory data retrieval and incremental sales data upload toward Lokad. Performances get greatly improved for recurrent usage.
• Build-in customization framework. LSSC comes bundled with LSSC Editor, a GUI tool that let you design custom inventory connectors for LSSC.

As LSSC gets out of beta, Lokad Desktop Sales Forecasting will be put in maintenance mode, since this application brings no additional benefits compared to LSSC.

Do not hesitate to check out the change logs.

Mea culpa. Choosing this name was really unfortunate and lead to many incomprehension.

Thus, I have decided to rename this parameter the period reference. It's default value is 2001-01-01 (i.e. Monday, January 1st, 2001), and unless you know why you need to change this value, I would strongly suggest you did not.

Let's start with a practical example. Let's assume that, as a retailer, you need monthly sales forecasts in order to make your monthly sales replenishment orders. Yet, your business months are starting the 15th of each month. All your suppliers are expecting your orders to be passed the 15th, and for years, all your monthly sales analysis have been starting the 15th.

In such a situation, it would be a real pain if Lokad was arbitrarily deciding that a month had to be starting the 1st. In order to avoid such a pitfall, Lokad provides an additional setting for the forecasting task definition that lets you adjust when you want the period to start: it's the period reference.

If you want your monthly forecasts to start the 15th of each month, then you can use 2001-01-15 as your period reference (or 1999-02-15 or 2017-11-15, the result would be the same). This date is used as a reference to infer all the other period's starting dates.

Further examples:

• If the period reference is set to 2001-01-15 for a yearly forecast, then all years start January 15h (instead of January 1st).
• If the period reference is set to 2001-01-15 for a weekly, then all weeks start on Tuesdays (because 2001-01-15 was a Tuesday).

In summary: The period reference, previously named "period start", is a date (past or future, it does not matter) used by Lokad to adjust the period boundaries both for historical data aggregation but also for the forecasts themselves. In particular, it has nothing to do with the starting date of the forecasts.

You can also check the complete change history.

For the Lokad customers, key benefits of open source components are

• no spyware, no badware. We don't ask you to trust us, you go and check the code yourself. We do our best to maintain a documented code, nothing gets buried in the dark.
• greater control on your IT infrastructure. Having the source code means that you can't be locked in (through proprietary file formats that could not be migrated for ex.).

Yet, as Jeff Atwood is pointing out, open source isn't only about disclosing the source code. His definition of open source involve further requirements:

• An OSI approved license. Lokad is using the (new) BSD license that allows code reuse into both closed and open source applications.
• The project must use a commonly available method of public source control. Lokad is relying on the Subversion hosting of SourceForge.NET. Thus, Lokad can't just take the code offline on its own.
• The project must provide public evidence that it accepts and encourages code contributions from the outside world. Well, you can check the Ohloh page of Lokad to have a look to see how many people are involved in those projects.

Also, on a more technical side, we have also setup a public build server. Our continuous integration builds include unit testing, automated code guidelines validation, and documentation generation. Check it out!

Among the key features that we are pushing forward for the first release:

• Retrieve historical data, such as call volumes and staff levels from your call center application.
• Visualize your data with filters such as day of the week (useful when it comes to compare the forecasts with comparable data over the last few weeks).
• Adjust call center queue settings such as expected service level or speed of answer, average call duration and wrap-up time.
• Convert incoming call volumes into staffing level suggestions with an embedded variant of the Erlang C formula.
• Edit staffing levels, if staffing suggestions need to be corrected.
• Export planned call volumes and staffing levels toward 3rd party applications.

We are already considering a native support for a couple of 3rd party applications such as Vicidial, Viev, QueueMetrics ...

Like the other Lokad products, L3C will be released as open-source. Do not hesitate to make your own feature requests.

We are proud to achieve a 12/12 on the Joel Test, and our goal is to make Lokad a really nice place to work. Open positions include

• Software developer
• Intern in software development
• Intern in marketing
• Intern or PhD with a mathematics or statistics background

For development works, we are looking for highly talented developers that are willing to take important responsibilities right from the start. We are way too small to afford having people doing less than useful work.

Considering that Lokad is also involving a lot of hard-core mathematical aspects, we are also willing to consider brilliant junior mathematicians with little or no programming experience. We will provide the necessary training to let you turn your mathematical ideas into industrial-strength applications.

Lokad offers the possibility to do a PhD in Computer Science within the company after an internship. Such PhDs get co-directed by Lokad and French university.

Also, we are also proud to mention that Lokad has been selected by ScrewTurn - the open source ASP.NET wiki used for www.lokad.com - as the first reference for their category Who is using ScrewTurn? Granted, the Lokad technology has little to do with this second selection. :-)

It is far better to foresee even without certainty than not to foresee at all. Henri Poincaré in The Foundations of Science, 1946

This situation is typically dealt with through an estimation of the forecast error: in addition to the forecast itself, an estimate of the forecast error is also computed. For example, this is the suggested approach for safety stock calculation.

Thus, we have decided to extend the Web API with estimated forecast errors. For any forecasting task, it is now possible to retrieve the Mean Absolute Percentage Error, see GetMape and GetMapes web methods. The new version of the Web API stays fully compatible with the existing applications.

Soon after the initial release of Lokad Desktop Sales Forecasting, it did become clear that both retailers and manufacturers were needing a deeper analysis than just sales forecasts. In particular, safety stocks that optimize the desired levels of service were among the most frequently requested feature.

Our initial specification for the "safety stocks" application includes a report that displays, for every product (or every SKU if there are multiple storage locations),

• Past sales (grabbed from a 3rd party software).
• Future sales (forecasted by Lokad).
• Stock level (grabbed from a 3rd party software).
• Stock coverage (computed), the time to reach the stock out if no reorder is made.
• Supplier (manually entered), just to be able to sort the products against their respective suppliers.
• Lead time (manually entered).
• Service factor (manually entered), the desired probably to get a stock-out.
• Reorder point (computed), the suggested amount of inventory that should trigger a reorder.
• Delta stock (computed as stock at hand minus reorder point), it tells you how much over-stock you have.

Like we did already, this application will be released as open source under SourceForge. If you think we should include more features, do not hesitate to contact us or to directly submit a feature request.

Lokad is only looking at historical data, and since we don't know that the exceptional sales aren't going to happen again (expert knowledge), this event is going to be interpreted as "real" sales, leading to potentially over-estimated sales forecasts. This situation is a typical case of demand forecasts vs. sales forecasts.

At this point, the natural solution would be to give the user the possibility to adjust the historical data to truly reflects the demand. We are currently working on a solution dedicated to safety stock calculations that would handle this sort of situations. Stay tuned.