Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

Dear Santa,

Me and my colleagues have been really hardworking this year, struggling to make the ends meet in our customers' B1 implementation projects. You know, it's not always easy, but somehow we get by.

I've learned to live with the idea that year on year we are getting less and less new bells and whistles in B1. That's understandable now that you've got the new ByDesign family and all that stuff. Therefore, I will make my wishlist real short. I'm also only including wishes that have a general appeal to the B1 community at large.

Wish 1: Make the item group and business partner group fields longer

I'm starting with a real no-brainer, just to get you warmed up.

Surely I'm not the only one who's seen their customers suffer about the current maximum length of item group names and business partner group names. I mean, come on man, 20 characters? I'm sure you can do better than that.

While you're at it, it would be nice to have a separate key field for the item group code as well. Currently there's just the system-assigned internal key that starts from 101. Many customers are used to a certain numbering system for the item groups in their previous system. When migrating to B1, quite a few of our customers have ended up adding this code in front of the item group name. Using this workaround, they can get the item group names listed in the order they want, but on the other hand they are forced to make do with even less characters for the actual name. Let's start with something simple like this:

Item Group Code: 837
Item Group Name: Twisted Pair Cables

To make that fit into 20 chars, I would use something like this: "837 Twisted Pr Cbls"

But what should the customer call an item group such as "Heavy duty Zirconium-coated platinum tweezers" ? You think I'm exaggerating? Maybe a little.

Let's move on business partner groups. There are many relevant ways to group customers and suppliers, but one of the most usual ways would be to group them by industry. For instance, SAP expects me to select an industry of the customer from a list each time I issue an order for software licenses. I just checked the industry classification of one our my favourite customers in the SAP SMB portal:

Automotive
Industrial Machinery
Industrial Trucks, Tractors, Trailers, and Stackers

As we know, the business partner grouping system in B1 is flat. For simplicity, let's just forget the two higher-level groupings. Let's concentrate on "Industrial Trucks, Tractors, Trailers, and Stackers". That's 51 characters. Now, try squeeze that to 20 characters !!


Wish 2: Provide us with structured address information in documents

In the business partner card, it is possible to specify several billing and/or shipping addresses. Each one of these addresses are structural in the sense that there are separate fields for street, zipcode, city etc.

When creating a document such as an order or invoice, this address information is used as the default value for billing and shipping address on the document. It is also possible to manually modify or completely replace either of these addresses. That's essential, as it could be that the customer wants the goods shipped to another location just this once (and thus it would be overkill to create a new address in the BP record). However, the addresses that are stored with the document are no longer structural. Each of the addresses is stored in a 254 character alphanumeric field, lines separated with carriage returns symbols. Well, if you only need to print that information on a piece of paper, that's pretty ok (even though the 254 chars space is less than the total characters possible in the street, block, city and zipcode fields, that's usually enough). The trouble starts when you need to pass the address information forward electronically.

We have lots of customers who are either using EDI solutions or sending XML-based electronic invoices to their customers. The standards that these solutions are based on require that the addresses are structural in the same manner as in the BP records. Ok, in some cases you could manage by just using those addresses specified in the BP record, but in quite many cases the customer wants to be able to specify the address each time they create a new order. We've learned to circumvent this problem by creating our own structured address fields on document header level and using those instead of the standard ones. It's ugly and kludgy, but it works. The default address is then retrieved to these fields by using formatted search, which brings me to my next topic.

Wish 3: Fix the formatted search

Formatted search is a feature that looks really fantastic at first sight. With a good grasp of SQL and a bit of imagination, there's some really fancy stuff you can do with it. However, it also has some really annoying shortcomings. One is that you can only attach a single trigger to each formatted search. Also, a row-level trigger is only fired when the user exits a field, not when the value is changed. Let's say that I want to calculate a value in a certain row-level field each time either quantity or price is changed. I just can't. Well, I could attach the trigger to a header-level field, say DocTotal and specify that it is "refreshed regularly". Sometimes that works, sometimes it doesnt.

Another annoying property of formatted search is that it changes the focus of a field. If I have lots of columns in the document and a formatted search is triggered in some of the fields in the east end of the grid (that I normally need to scroll to in order to see them), the whole grid is focused so that I no longer see the most important fields that I want to see (such as itemcode and quantity) when adding a new row.

The worst thing about formatted search is that I can never trust that it will work the same way after an upgrade. The biggest problems have been related to how formatted search is triggered in fields that are either hidden or non-active. They used to work fine. Then, at some point around SBO 2004 PL21 they stopped working. By popular demand, they came back a few patch levels forward. Now, we have again faced the same problem in SBO 2005 SP1 PL31. A few days back we heard from the always helpful SAP Support Helpdesk that the "system works as specified" as formatted search is "not officially supported in hidden or inactive fields". That just about eliminates half of the solutions that B1 partners worldwide have built with formatted search in order to overcome shortcomings in the standard functionality of B1. Recently I have also been told that formatted search is not officially supported in the system fields with orange arrows. Now that's another bummer that renders the formatted search pretty useless in many cases. I mean, what's wrong with you guys? I thought formatted seach was one of those killer features that made B1 so powerful. I've also heard that one of the greatest features of B1 is that the upgrade is a breeze and everything will work the same after an upgrade. What a lot of baloney !

Please Santa, could you at least try to convince the dev team of the importance of formatted search functioning consistently between different patch levels (and fix the current mess with the hidden/inactive fields ASAP) ?

Fix 4: Stop consolidating lines in journal entries based on other documents

So far this has mainly been a nuisance for our existing customers, but this year we lost one big case (with plans on rolling out B1 to multiple locations worldwide) to Dynamics NAV solely because B1 only allows two financial reporting dimensions (project and cost center) to be automatically copied from sales and purchase documents to journal entries. To make things worse, B1 always consolidates the automatically posted journal entry lines per project, cost center and tax group. If B1 would generate separate lines for each source document line and store the information of base document and line number, there wouldn't be any problem as we could always trace back from the journal entry line to the document line. Currently, we can't.

It can't be so hard to add a possibility to have B1 add a separate line in the journal entry for each document line, can it? This can't be a database space conservation issue, as B1 is rather wasteful in many other less important places.

Conclusion: get your act together

I really hope that you will get your act together in 2008. I hate to say this, but otherwise I'm afraid that next Christmas I'll be addressing my wishlist to the Big Bad Santa that lives in Redmond with his Dynamics family.

4 Comments
Labels in this area