Skip to Content

My Christmas wishlist for Santa Claus

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:

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.

You must be Logged on to comment or reply to a post.
  • 1) How about a reverse backflush screen, or at least the ability to perform a negative completion in the existing receive from production screen? Trying to fix an accidental completion to stock can be a nightmare.
    2) How about the ability to reverse a delivery? Oh, I know the return screen straightens up the business partner and inventory transactions, but what about that pesky backlog? The backlog needs to be restored, in case the user just made a mistake.
    3) Granted the US has a culture of credit, but why aren’t the down payment request / invoice screens available for the US and Canada? And since they don’t exist, why display them in the help as being the solution to our problem?
    4) Voiding checks, outgoing payments and the check file. We used to call these bugs. Enough said.
    • Hi Omotayo,

      In fact I got a response. Not directly from Santa, though, but from one of his trusted goblins. Here’s the content of the message:

      [Hi Henry ,
      I have sent your ‘Christmas wishlist for Santa Claus’ to our development managers and will update you with news.
      I did not know the direct mail of Santa Claus, but in case you meet him, please let him we are working on it.

      All the best and happy new year,

      In my response, I mentioned a specific additional request:

      [Would it be possible to have a Remove method in all the ‘lines’ object (meaning objects that currently have the ‘SetCurrentLine’ and ‘Add’ methods) ? As an example of these, ItemWarehouseInfo is perhaps the most common one that’s really screaming for such method (please read the latest feedback comments in the B1 Turbo Command host blog for more details about this). I’m sure there has been some good reason for not implementing this method in line objects before, but I really wish the SDK Dev Team could reconsider it.]

      …here’s his reply:
      [Hi Henry,
      For each object  there is a DRQ and  it  requires seperate & different effort.  some objects do not allow delete line  in any case.
      Can you please me know in which objects you want the  –  delete line.]

      …and my answer:

      [From my own and our customers’ experiences, I would say that the ItemWarehouseInfo is the most critical one. This is because it is quite easy to cause a situation where thousands of ItemWarehouseInfo records are generated automatically (without asking the user) and currently there is no other “legal” way to delete them but brute force (manually one by one).

      This is one example how it may happen:

      – The system has the setting “link all items to all warehouses” selected
      – The user goes to the warehouse definition screen, assumes that she is in search mode, types ‘*’ in the warehousecode field and clicks enter.
      Bingo – now the system has as many new ItemWarehouse records as it has items. To make things worse, now the warehouse ‘*’ can no longer be removed as there are items attached to it. This has actually happened to a couple of our customers.
      Of course it would be “nice to have” the Remove method in Document_Lines etc, but ItemWarehouseInfo is definitely the most important.

      Best Regards,

      Since this message exchange which happened in  January 2008, I haven’t heard from them. Hopefully there has been some progress – I know they are trying hard. Still, I can’t help the feeling that they are fighting against windmills. The product was very promising back in 2003-2004, but it’s getting old and seeing very little actual progress. This might just be a rumour, but I heard from a guy who used to work at SAP Support that at one point the whole dev team who originally developed the product had left the company. Anyone who’s been involved in software product development knows that this is about the worst thing that can happen.

  • As the author of this blog, I must say that I’m surprised that SAP was only able to deliver one out of the four requested features during the past three years. Back then I even got personal email from a SAP product manager who promised to send these requests forward. In my humble opinion, these were all moderate and justified requests.

    As a consultant and developer, I know that at least the first request would’ve been both relevant from business point of view and extremely easy to implement technically.

    I must admit that comparing with the past “upgrades”, there are some worthwhile fixes and new features in 8.8 (although the “archiving tool” was a big bummer). Still, is it too little too late? Time will tell.