The LawsonGuru Letter, brought to you by Decision Analytics  

February 2006


Click here to forward to a colleague


In this issue:
1. Guest Spot: Processing Consignment Inventory in Lawson
2. Se Habla  . . . Lawson?
3. Reader Feedback
4. Worthwhile Reading
5. Lawson Tips & Tricks

The LawsonGuru Letter is a free periodic newsletter providing provocative commentary on issues important to the Lawson Software community.  The LawsonGuru Letter is published by—and is solely the opinion of—John Henley of Decision Analytics.

Visit Decision Analytics at For subscription information, see the bottom of this message.  The LawsonGuru Letter is not affiliated with Lawson Software.

In last month's article on the release of LSF 9.0 (see, it seems I was a bit too enthusiastic and misinterpreted Lawson's future product direction as being included in this release.  So, please see the Reader Feedback below for an important clarification from Lawson's Chief Product Officer, Dean Hager. 

  1. Processing Consignment Inventory in Lawson )  
  Consignment Inventory is inventory that is in the possession of the customer, but is still owned by the supplier. In other words, the supplier places some of his inventory in his customer’s possession (in their store or warehouse) and allows them to sell or consume directly from his stock. The customer agrees to accept the goods without any liability, except to exercise due care and reasonable protection from loss or damage. The customer purchases the inventory only after he has resold or consumed it.

The benefit to the customer should be obvious; he does not have to tie up his capital in inventory. But what’s in it for the supplier? The Consignment inventory model can be effective with service parts and/or critical equipment where the customer would not normally stock certain service parts due to budget constraints or demand uncertainty. Consignment inventory allows the supplier to provide a higher service level by having the parts immediately available and saving the customer expedited freight costs. Incidentally, the supplier also ensures the customer does not procure a replacement part from a competitor. The key is the combination of a high-degree of demand uncertainty from the customer’s point of view, and a high degree of confidence in the sales potential from the supplier’s point of view. The following scenarios are typical for Consignment relationships:
  • New and unproven products
  • Introduction of existing product lines into new sales channels
  • Very expensive products where sales are questionable
  • Emergency situations where restocking time is critical

Thus, a Consignment relationship is beneficial for all parties. When pursuing Consignment, both parties need to clearly agree upon the terms. Important considerations include:
  • Real-time sales or period-end sales
  • Time limit (must be purchased or returned within specified period)
  • What is the freight policy?
  • What is the return policy?
  • Who holds responsibility for damage or loss while in customer’s possession?
  • What are the Insurance implications?
  • Exactly how and when is data exchanged? What data is exchanged?
  • How are miscellaneous transactions processed?
    • Cycle count adjustments
    • Customer Returns (does a return initiate a credit from the supplier?)
    • Scrap

To process Consignment in Lawson Inventory, set the Consignment flag on IC11 and/or IC12 so that the value of these items may be excluded from valuation reports IC233/IC234. Outside of the valuation exception, Consigned items are treated in the same manner as regular inventory and using them is transparent. Consigned items can be included on Templates, and can have automatic reorder policies and agreement pricing to facilitate the Consignment relationship.

Consigned goods are treated differently from an accounting perspective. The customer should be extremely careful not to include any of the goods Consigned as a part of inventory. Therefore, it is a good idea to create a separate GL Category to isolate Consignment transactions to a unique Consignment Account (this account could be excluded on GL reports):

On IC04, set the Receipt and Inventory accounts to be the same. This will allow a “wash” affect when recording the initial Consignment level via IC20.

Use IC20 to establish the initial stock on hand without creating a PO/Receipt. If the GL Category is setup correctly, IC130 will post an equal debit and credit amounts to the Consignment Account. Because the initial inventory is not owned by the customer, the AP liability is not necessary. Instead, we must record the AP liability only when the Consigned goods are consumed. For this reason, it is most efficient to have reorder points and automatic purchasing associated with Consigned inventory. That way, when shipment occurs via requisition or other form of issue, the stock depletion initiates the PO, Receipt and Invoice cycle. This cycle does the following:

a) Records the Issue/Consignment Inventory journal entry
b) Replenishes the Consigned stock
c) Provides the vendor with payment for the depleted stock
d) Records the Consignment Inventory/AP journal entry

If you don’t utilize reorder points and automatic purchasing, someone has top manually enter a purchase order to pay the vendor and replenish the consumed stock. Regardless, it is a good idea to have a special Buyer code or PO Code that can be used to distinguish Consignment purchase orders. Make sure you have reports that can aid in reconciling the Consignment account.

Sometimes business arrangements with the vendor require the customer to track specific components, for example, to enforce product warranties. Serial tracking can be used to satisfy this requirement. When the Serial Tracking flag is set on Item Master IC11, the user is required to enter additional details when receiving or issuing:

Serial details are stored in the related file called ITSERIAL. You can Drill Around on an item to find out which serial numbers make up the stock on hand, and query ICTRANS to determine which serial numbers have been issued (using Lawson MSAddins or Crystal Reports).

In order to notify a vendor about which serial numbers have been consumed, you’ll need to make some modifications to the Purchase Order. To accomplish this without significant modifications, you are probably limited to using a user field on the PO line. If you want to make this a little easier on the buyers, you could modify PO23 to have a drop-down from ITSERIAL for the item on each PO line:

Then, their selection would be written to a custom table, a user field on the PO line, or to the PO line comments.

Making the PO form modification in Design Studio might be a little less intrusive (you wouldn't be modifying PO20/PO23 base code, you'd be layering on top of it), which would help you from a maintenance and support standpoint. In other words, if you modified the LID version, you'd have to reapply those modifications after installing CTPs and/or MSPs.

Once the serial number is captured on the PO line, you will need to get that information to the vendor as part of the PO. How this is done would depend on how you issue your POs, (i.e. running them thru printing software or sending an EDI file). With printing software, you have a bit more flexibility for doing database lookups, etc. If printing on plain paper or sending an EDI file, you will need to make the modifications directly to the files created by Lawson.

There are many factors involved in managing a Consignment inventory, and success begins with trust. Both the supplier and the customer must allow the program ample time to develop; tweaking and learning from each other along the way. Both supplier and customer must be “on the same page”, and there are a variety of metrics that can be shared to measure progress. Included among the metrics are the number of Purchase Orders per month, total transportation costs, the number of items returned to the manufacturer & the costs involved (both on the manufacturer & distributors side).

So what are key performance indicator(s) for monitoring the Consignment process? There are four KPI's for monitoring the success of a Consignment program:

  • Inventory Value
  • Inventory Turns
  • Fill Rate to the customer (Service Level)
  • Fill Rate to the customer’s customer

ABC Classification should be used to classify each down if possible, using the Movement Class for the item:

Once the Consignment relationship begins, regularly review these KPI's by Movement class, comparing the current levels to pre-consignment levels and to the target level. It is only through this type of before/after comparison that you can get a clear picture of the success or failure of your program.

  2. Se Habla . . . Lawson? )  



Here’s a quick overview of how Lawson supports (and in some ways, doesn’t support) multiple languages, known in the industry as “ERP Localization”.

It’s a question I get periodically. What are the languages (i.e. Spanish, German, French etc) that Lawson supports? How does it work? For the clients who are (or perhaps are just considering) expanding internationally, one of the basic requirements is that their ERP package support it. Oftentimes, however, this is an afterthought. Only after the big expansion plans have been unveiled does it fall to the IT infrastructure to implement and support it. So, here’s a quick overview of how Lawson supports (and in some ways, doesn’t support) multiple languages, known in the industry as “ERP Localization”.

First the good news: Lawson supports a few languages, in addition to English, when displaying screens and generating reports. This includes field labels, help text, and the like. What Lawson doesn’t not support is the ability to store multiple versions of language-specific data. In the database, what you key in (or more specifically, what language it is typed in), is what gets stored in the database. In other words, if you type in an item description on IC11 in English, when a Singapore-based user sees it, it’s displayed in English. While the field labels are translated as they are rendered, the data itself does not.

There are a couple of exceptions (for example, Dunning Letters can have language translations by keying in multiple versions of language-specific text on AR19). But for the most part, the rule is: language in—language out.

This may or may not be a showstopper. If you operate in multiple countries, and can geographically separate the duties (i.e. language-specific Companies, Activity Groups, etc.), you’ll probably do just fine. The users will see their language-specific field labels, and can type in their data in whatever language they choose, as long as Lawson (and your underlying database) supports it.

So, what languages does Lawson support? For 8.0 Applications, Lawson provides translation files for the following languages:
  • Dutch
  • French
  • French Canadian
  • German
  • Italian
  • Latin Spanish

However, for 8.1 Applications, the list is a bit shorter:
  • French
  • French Canadian
  • Latin Spanish

As for why Lawson supports fewer languages with 8.1 applications, I have not been able to get a reasonable answer. Here’s the official support response I received:
    There are no plans to support Italian. You would need to make a request to your client manager for the additional language to have it reviewed. This would not guarantee an Italian language file would be created, but it would be a starting point.

However, I have found that loading the 8.0 translations will work OK with the 8.1 applications, although you will need to manually add some phrase translations.

Even so, it’s still a pretty short list, since the Lawson architecture does not support double-byte languages (i.e. Kanji, Hansa, Arabic, etc.). This, of course, is rumored to be included in the future, as part of the Landmark initiatives.

So, if your language is in the above list, here’s how to get started:

Download the language translation files (and a short document on installing them) from the Product Downloads section on Lawson's support site, and use the ldlang utility to install it:

- Use the locdef utility to create a locale in the Environment and assign the language to the locale

Use laua to assign the locale to desired users:

Users can also set their locale from the Portal’s User Options form:

As Lawson applications are compiled; phrases on screens and reports are stored in the GEN table PHRASE & PHRASEUSE. Translations are stored in GEN table PHRASEXLT. - You can use the langdef utility to make any manual translations.

In addition, the Lawson forms are compiled into language-specific files, called ”tranmaps”. When you first install a new language, you’ll need to use the genformap utility to generate tranmaps for all of the forms in your product line(s). As forms are re-compiled, they will be updated automatically.

Once the phrase files and tranmaps are built, when the screens/reports are rendered, translations are done based on the language for the user's locale. Here’s a sample from LID:

Pre-rendered (.xml) Portal screen files (i.e. tranmaps generated by xscrgen) are stored in $LAWDIR/<productline>/map/ which are loaded by Portal users:

As you can see, Lawson does take care of a lot of the localization requirements for displaying forms and generating reports. While we’re on the subject of globalization, I’ll answer the other question I always get: “Can we pay our employees in...?”  Sure, as long as your list is limited to the US, Canada and the United Kingdom. While Lawson does a pretty good job on currency translation for most of your financial transactions, and you can certainly pay employees in the currency of your choice, Lawson won’t be able to calculate their taxes nor adhere to local wages laws. For that, you’ll be better off choosing a payroll service, and interfacing the transactions back into the Lawson Financials.
  3. Reader Feedback )  
In last month's issue (see, I shared my thoughts on Lawson's 9.0 release.  It seems my enthusiasm got the best of me and I was perhaps a too hopeful regarding the scope of this new release.  Which elicited the following response from Dean Hager, Lawson's Chief Product Officer:
Thank you for writing about 9.0, and frankly, for endorsing the direction. I know you always provide your honest opinion, whether its favorable or not.  In your article, a couple of comments panged me a bit, and I wanted to make sure we are clearly communicating.

While you are absolutely correct regarding our ultimate goal of removing "proprietary plumbing" and replacing it with standard IBM middleware to allow our clients to manage and maintain Lawson software better, we are not 100% there yet.  In LSF 9.0, dbreorgs and install CTPs are still there. When planning for the LSF 9.0 release, we chose to focus our efforts on leveraging the scalability, security, and standardization aspects of IBM's WebSphere. In subsequent releases, we will leverage WebSphere to simplify product lifecycle management, especially in the areas of upgrade, patch management, and usability.

Hope this is helpful. Thanks again.

I also received this response, from another member of the Lawson community:
“I was intrigued by the statement you made in your recent newsletter saying that "Since Lawson has actually scrapped the 8.1 Technology release......", which is really untrue. the 9.0.0 Technology release is merely a re-branding of what would have been 8.1 SP1, with the exception that the IBM Blue stack are now bundled.

I believe that your statement was somewhat misleading to the Lawson Clients.
Of course, there are always some in the crowd who are not as enthusiastic:
“This [LSF 9.0] is simply about minimizing their QA cycle and costs and being able to expedite the de-commission of 8x, thereby minimizing their support costs whilst giving them (and their blessed partners) a vehicle for services revenue. Oh yeah... do you think IBM might have put some skin in the game? I'd bet you a nickel that there will be a LOT of blue COBOL programmers hanging around St. Paul over the next fiscal year...
As always, you're always welcome to share your thoughts--simply send me an email at
  4. Worthwhile Reading )  
  Lessons from an SOA pioneer
Shipping company Con-Way began its SOA journey eight years ago, providing one illustration of how the new architecture approach can go the distance
Infoworld, January 06, 2006


“The middle of every successful project looks like a disaster.”

-- Rosabeth Moss Cantor

Staying Power!
COBOL has become UNICODE—compliant, object oriented and XML friendly.
Application Development Trends, December, 2005

Blueprinting your Database Landscape
Crafting a map of your database servers can help you build better systems, from increased security to solid disaster-recovery plans.
Enterprise Architect, Fall 2006

Surviving the Software Vendor Shuffle
Software vendors were wheeling and dealing this year. Oracle Corp. announced or closed nine acquisitions, led by Siebel Systems Inc. and Retek. Microsoft Corp. purchased nine companies, including collaboration software firm Groove Networks Inc.
Baseline Magazine, December 2005,1540,1896611,00.asp
  5. Lawson Tips & Tricks )  

Another Process for Mass Asset Disposal

In one of your newsletters (see, you published a tip for disposing assets.  I was involved in a major project and I had figured out another way to do mass disposals of assets which don’t have anything in common with each other.

First, create an attribute on AM23.1.  Then create an Excel upload template so that you can attach this attribute to all of the assets that you want to dispose of.  After the upload is complete, you create a list, and run the AM145. This works like a charm and is really easy.

Please share The LawsonGuru Letter in whole or in part as long as copyright and attribution are always included.

Decision Analytics is an independent consultancy, focusing on Lawson technical projects, and specializing in reporting, customization/modification, data conversion, and integration/interfaces. Please visit for more information.