Skip to main content

Best Practice for Structuring Multiple Ship-To with Single Bill-To Data in Acumatica?

  • 28 November 2021
  • 10 replies
  • 1078 views

I am trying to figure out the best practice to structure my data for a scenario where I have many ship-to locations for individual billing addresses for a company.

It seems to me that there are two possible ways to do this.

The first would be to create a new customer for every ship-to location and then use the “Parent Account” relationship to link it back to some master account. Is there a way to derive the billing address from this parent-child relationship (child inherits bill-to of parent by default?) What are the options/consequences for financial reporting with this setup?

 

The other way to do this is with the “Customer Locations” feature. So I would create a single Bill-To Customer, and then attach all the Ship-Tos as locations to that customer. The main issue I see with this is that I don’t see a way to attach Contacts to individual locations with this system. So if you have a large conglomerate with a bunch of different locations, there doesn’t appear to be a way to default or subselect just the contacts that are relevant to that location when you choose the location on a Sales Order, for example.

 

I’m sure others have run into some of these issues in the past. I would love to hear anecdotes or suggestions for best practices here.

 

Thanks,

 

Jonathan

10 replies

C
Rank
Userlevel 7
Badge +9

Hi @rosenjon 

child inherits bill-to of parent by default? No. The Bill-to-Address does not inherit from the parent, as each child can have its own billing address. You have to add the child’s billing address. or a customization should be added to populate the billing from the selected Parent.

Thanks

Chandra M
R
Rank
Userlevel 6
Badge +5

Yes upon further research I found what you mentioned, which is that this would be a coding project to inherit the bill-to address from the parent customer. I think that this should be a future feature request, since there is already a chain of address override options starting with MainContact, and overriden by BillingContact, ShippingContact and then optionally by LocationContacts. Honestly, Acumatica needs to do a better job of documenting this whole setup. Most of what I know about it has been through trial and error.

 

I will answer my own question here. Clearly, the cleanest way to do what I want to do is to set the MainAddress property of the customer, and then to override the Bill-To (but not the Ship-To). The default address search in the Sales Order screen provides a way to search on Address Fields with a very quick customization to the FastFilterField property of that Selector control (add Address.AddressLine1, for example, as a FastFilterField). That search happens against the MainAddress field. So if you allow the Ship-To to default from MainAddress, and you override the Bill-To at the Customer level, you in effect have a search against the ShipTo Address. Again, not intuitive at all, and not really documented, but I have tested this setup and it works. The downside of this approach is that the Bill-To address will have to be updated across all children when the parent changes, but this is a fairly simple coding customization, more so than joining/searching multiple locations from the top level customer search.

C
Rank
Userlevel 7
Badge +9

Hi @rosenjon Thanks for the details and the approach you are taking. Just to summarize here, so that it is useful others looking for a solution. Please review and confirm.

Approach Considered:

  1. User Parent- Child customer relations. This option has to be enable from”Enable/Disable” option if the “Parent Info” section not visible in Customers screen.
  1. Contacts can be maintained at each child customer level. Just like individua; Customers
  2. Billing-address can be entered same as Parent.
    1. A customization for auto-populating the billing address from Parent Customer, if required, 
    2. A customization to show the address fields on the selector.
  3. Payments can be applied at parent level, if required.

Thanks

Chandra M
R
Rank
Userlevel 6
Badge +5

Hi Chandrasekhar-

Yes all of your points are correct. I think that point 2, related to contacts, is also especially important and useful with the scenario I propose. If you go the route of having a single bill-to as the top level customer, with a bunch of locations as possible ship-tos, this forces you in Acumatica to group all contacts under that single customer, which in effect makes all contacts for every location available for any ship-to customer. This may be desirable in certain circumstances, but for us, it is far more common that the contact is related to an individual ship-to location, and therefore it is better to have those contacts only attached to those ship-to locations. This is only doable if those are separate companies.

Clearly the most challenging issue with this setup is the synchronization between parent account and children from the bill-to. However, this is very amenable to API based approaches for verification and synchronization, as well as customization project approaches, so I think it is the correct direction. I would hope that at some point Acumatica would make bil-to/ship-to inheritance down the parent-child customer chain an option.

Thanks,

 

Jonathan

C
Rank
Userlevel 7
Badge +9

Hi @rosenjon Thanks for the details. Thanks for your confirmation on the approach you are taking. This will be useful for others seeking for assistance on the same topic.

 

Chandra M
Neil Cantral
Rank
Userlevel 5
Badge +3

How you set it up really depends on how you want to manage the account. This is by no means an exhaustive list, but here are some of the key questions I walk through:

  • Other than addresses and contacts - do all locations receive the same pricing/shipping rules/ credit terms/commissions?
  • Is every location serviced by the same internal sales/customer service team?
  • Does the customer require separate statements/balances per location?
  • Do all locations share a credit balance or require credit approval if one location has fallen behind on payments?

I strongly prefer one account with many locations when the locations are mostly homogenous with the main difference being the ship-to location and contact. This has been easier to teach users and simplifies reporting. This becomes increasingly difficult to manage as differences in how locations are managed begin to compound.

Parent-child setups are nice when locations have fundamental differences like separate billing statements and AR balances, differing sales territories, or fall under different sales agreements.

We have a mix of both. The vast majority of our customers are single accounts with multiple locations. Any exceptions are handled by parent child accounts. Our most common setup for these is when a customer is split into a domestic account, an international account, and dropship account. Each of these has special circumstances requiring a separate account and to making reporting easier. For example a customer may have locations in Canada that are not subject to tariff price increases and are managed by a separate Payables team so those locations are rolled up into a new child account. A customer that participates in a dropship program may get different discounts/commissions/credit terms configured as a new account.

R
Rank
Userlevel 6
Badge +5

Hi Neil-

Thanks for adding your feedback. My initial thought was that the single billing customer with multiple ship-to’s as locations was going to be the cleanest and easiest to manage setup. However, I don’t think the out-of-the-box configuration of Acumatica makes it that easy to do. For example, the default Sales Order workflow has you select a Customer, then a Location and then optionally a Contact. What if the Ship-To customer is named something different than the bill-to customer? This happens quite frequently. You can name the ship-to location something else, but you can’t search the ship-to location until you’ve chosen the top level customer. So this creates a very difficult situation from a search usability perspective. Obviously, it’s very use-case dependent. But we need to be able to search on the customer’s ship-to address to find the customer, and I don’t see any way to tap into native functionality for this without making the base customer a ship-to customer with a parent record for the bill-to.

There are also some of the other challenges I mentioned, like contacts not being able to belong to locations, thus making all contacts appear for every ship to location.

I think Acumatica has some work to do with customer workflows to make this functionality more flexible. It is good for a specific workflow use-case, but not so good for others. For example, why can’ t you choose the ship-to location first and default the bill-to and contact based on that? I think with a little more work they can make this better, that’s partly my motivation for the posting. I have seen a number of threads out there that deal with various aspects of this same problem.

 

Thanks,

 

Jonathan

mvolshteyn
Rank
Userlevel 5
Badge +3

@rosenjon , I agree with @Neil Cantral  that having a single customer with multiple locations is a preferrable option when only shipping locations are different while ar part is the same

I agree that a predefined sequence of fields entry into sales order might not work wekk in all cases. However, but the problems which you outlined seem to be resolvable by custom tools or code customizations.

  1. “What if the Ship-To customer is named something different than the bill-to customer? This happens quite frequently. You can name the ship-to location something else, but you can’t search the ship-to location until you’ve chosen the top level custom”

    You can set up a generic inquiry showing shipping addresses (with quick search functionality) and customer id and location. So, users might from this GI, then navigate to customer id, and click Create New Order. It should take just few extra clicks
  2.  “There are also some of the other challenges I mentioned, like contacts not being able to belong to locations, thus making all contacts appear for every ship to location.”
    This can be achieved by a code customization, probably of moderate complexity. Let me know if assistance here is needed 
MarkV
R
Rank
Userlevel 6
Badge +5

Thanks Mark. I have seen some other suggestions related to the customer location lookup that also recommended similar types of workarounds to your GI suggestions. For example, you could open the Customer Locations screen and search the address, and then backsolve the related customer for entry into the Sales Order screen.

I think the problem with these solutions is that they are unacceptable from a workflow perspective, given the volume of lookups done each day. If this was a pretty rare occurrence, where someone only had to look this information up once in a blue moon (maybe for sending a one-off invoice to some other location for example), then I would say it’s fine. The problem is that this is basically what the whole company is doing all day every day. So now an entire company of people is having to implement the workaround hundreds or thousands of times a day, and I see that as unacceptable overhead. Sometimes as software devs, I think there is a tendency to say “I have a solution for you”, but you have to consider how often that solution needs to be implemented, and how cognitively burdensome it is relative to people getting their work done.

While creating a parent-child account structure is not strictly necessary in this case, it does have some advantages, and mostly it allows us to implement a solution without hacking up the software with customizations. It works out of the box, and hopefully Acumatica will see fit to enhance the searchability of the Customer data in the future, at which point we could always restructure the data to do Locations. Most importantly, it allows the end users to search the Customer address in a rational way that is built into the native Sales Order screen. Any synchronization that needs to happen with billing addresses can be handled in software also, so I see it as the superior solution.

It also solves the Contact-Customer branch relationship problem, again without code modification.

M
Rank
Userlevel 6
Badge +5

Given your requirements I would agree that the parent-child relationship makes the most sense. Adding a toggle to pull in the parent’s billing/shipping address would be a pretty simple customization and the rest of the problems are solved by isolating the child locations as separate customers. 

Reply


Terms & ConditionsCookie settings