Developer forum

Forum » Development » ERP payment & shipping method ids

ERP payment & shipping method ids

Arnór Halldórsson
Arnór Halldórsson
Reply

Hi,

Can we add a standard field to shipping and payment methods for the corresponding method´s ID in the ERP system?

Today we either manually map this in code or we use a shipping provider to include this parameter, which get's annoying when you start to integrate with multiple shipping / payment providers.

Best regards,
Arnór Geir


Replies

 
Nicolai Pedersen Dynamicweb Employee
Nicolai Pedersen
Reply

Hi Arnor

Can you ellaborate a bit? You want an extra id on the shipping and payment methods, or on the order?

BR Nicolai

 
Nuno Aguiar Dynamicweb Employee
Nuno Aguiar
Reply

+1

 

In fact I'd go a little further. These are our common needs in terms of data:

Payment

  • Payment method code (aka the ID in the ERP, because PAY2 is meaningless to them)
  • Payment mehod terms (used for Pay on account, we sometimes need to provide the Terms the user is paying on

 

Shipping

  • Shipping method code (aka the ID in the ERP, because SHIP4 is meaningless to them)
  • Shipping method agent code (i.e. "FEDEX", "USPS", ...)
  • Shipping method agent service (i.e. "GRD" , "2DAY", "OVERNIGHT")

 

Best Regards

Nuno Aguiar

 
Nicolai Pedersen Dynamicweb Employee
Nicolai Pedersen
Reply

@Nuno - sounds a bit implementation specific.

Is this on the payment and shipping records? Or is it on the order record?

 
Morten Bengtson Dynamicweb Employee
Morten Bengtson
Reply

Sorry for barging in, but...

As a workaround you could import the payment and shipping methods and give them any id you want (just avoid the standard PAY/SHIP prefix and special characters).
Additional information could be provided in custom order fields and/or the PaymentMethodDescription/ShippingMethodDescription on the order.

It might not be the ideal solution, but I think it would work if you need a solution right now?

/Morten

 
Adrian Ursu Dynamicweb Employee
Adrian Ursu
Reply

Hi guys,

+1 on this request.

We have seen this many times in the integrations. We had to have custom mappings between Dynamicweb IDs and ERP ids for Payment and Shipping methods.

The way I see it, and I am trying to make it as less specific as possible, is to have an additional field on the methods for ExternalID (PaymentMethodExternalID, ShippingMethodExternalID) and also store these IDs on the Order and Order XML in new fields.

The other additional fields suggested by Nuno are also useful and I can say that we could have sed them as Nuno described them in a few projects of ours. Therefore they don't seem project specific.

Thank you,

Adrian

 

 

 
Adrian Ursu Dynamicweb Employee
Adrian Ursu
Reply

Hi guys,

Morten's solution works if you want to handle everything from code/import. But in some cases, they can/should be handled from the admin interface.

I understand there are workarounds, and we have used them so far, but it makes it easier to maintain and setup if this would be available from the admin.

Thank you,

Adrian

 
Nuno Aguiar Dynamicweb Employee
Nuno Aguiar
Reply

Hi Nicolai,

 

Not implementation specific at all unfortunately. We store it in the Shipping/Payment method records, but just use it in Live Integration though, when exporting the order.

 

i.e.

  • For B2B , in Dynamicweb you set up "FedEx Ground" and "FedEx 2 days" as 2 separate shipping methods. This is pretty common (even a 3rd or 4th variation of FedEx)
  • In Dynamicweb that means SHIP1, SHIP2, SHIP3 and SHIP4
  • In the ERP they need to convert that into
    • Shipping Agent "Code" - which would mean "FedEx" or "FEDEX" or "FEX" - whatever they identify FedEx with
    • Shipping Agent "Method" - which would mean "Ground" or "GRD" or "2DAY"...
    • (I know I mentioned Shipping method too, but I don't recall how the integration team uses it and they are asleep still, so I can't ask them now, but it's used)

 

That mapping always needs to be set and is what allows the ERP to then integrate with the carrier and get the shipping labels, generate track and trace and whatnot according to the user's choice in the website.

 

The same process happens with Payment. Also because more than often in B2B (in the USA at least), a CC Authorization is performed in DW, then we integrate the order to the ERP, and the ERP, having also an integration with the same payment provider because of offline orders, it's the ERP that captures the amount (based on the authorization generated from DW). This means we need to say that PAY1 = whatever payment method code they have in the ERP.

 

Why set the mapping in DW and not the code unit/ERP?

The biggest reason is environments. Whether that's Dev, Staging, UAT, Prod we may be generating different methods, so DW's IDs sometimes don't match. i.e. SHIP10 in Dev may be SHIP8 in QA, but for the ERP it's the same.

 

Does that make more sense?

 

Best Regards,

Nuno Aguiar

 
Imar Spaanjaars Dynamicweb Employee
Imar Spaanjaars
Reply

+1 have seen this many times before too. A great solution would be to have custom fields on shipping and payment (or maybe at the ConfigurableAddIn level so you get it for other add-ins also). Then you define the fields once, and populate them for each individual shipper or payment or other addin.

Then using LI extensibility, you can grab the selected payment / shipping option, get its custom fields and append them to the order XML where you like.

Today, we do this by creating an area item type where we define the custom fields and associate them with each shipping. In the example below, I have a "Ship on pallet" option that is either on or off for each shipper. In LI I can then grab that value and use it.

 

While this works and mostly gives me what I need, having these fields directly on the shipper / payment would be much more user friendly. Currently a user would have to go to different places to set up a single shipper. It also requires some additional setup.

Imar

 
Nuno Aguiar Dynamicweb Employee
Nuno Aguiar
Reply

Oh wow... Adrian, Imar and Morten you guys wrote a bit while I was writing my post :P

I hope my "large" post explains a bit more the scenarios and how 1 single field is not enought for our needs at least

 
Arnór Halldórsson
Arnór Halldórsson
Reply

Wow guys, thank you for the reactions!

Nuno - You read my mind! The extra fields are definetily something we'd use as well, f.e. the shipping method agent service. I think we have a custom default shipping provider in all our projects just to get parameters that tell us if it's "DELIVERY" or "PICKUP".

Morten - We could import them, but I can think of a couple of reasons why I probably wouldn't solve it that way:

  1. These things hardly ever change their values on either end, and adding new payment methods happens rarely. So once their setup they stay as is pretty much throughout the lifetime of the project, or until the client goes through another ERP update.
  2. Could cause problems when we've added custom payment / shipping providers to the methods in DW.

Imar - Custom fields or having them configurable at the addin level is a great idea as well. That way each could customize the fields to their own specific needs, but wouldn't most of us be adding the same fields anyway?

I think that Nuno's suggestion would be the best fit for me and my team at least :)

Best regards,
Arnór

 
Anders Ebdrup
Anders Ebdrup
Reply

+1 for this feature request

 
Martin Grønbekk Moen
Martin Grønbekk Moen
Reply

+1 from me too

 
Dynamicweb Employee
Dmitriy Benyuk
Reply

Hi guys,
we are currently working to implement the feature you want and have come to the list of the fields that should now solve all your needs.
We tried to be close to the fields that we have seen in the BC and NAV.

The list of the fields:

EcomPayments
 PaymentCode [text[25]] (the ID in the ERP)
 PaymentTermsCode [text[25]] (the ID in the ERP)
 PaymentTermsDescription [text] (some long text description)
 
EcomShippings
 ShippingCode [text[25]] (the ID in the ERP)
 ShippingAgentCode [text[25]] (the ID in the ERP)
 ShippingAgentName [text] (some text)
 ShippingAgentServiceCode [text[25]] (the ID in the ERP)
 ShippingAgentServiceDescription  (some long text description)

The *Code fields have a lengh of 25 since in BC the Code fields are 20 chars length,
let us know if you have more length in your Code fields.

Those fields would be added to the Dynamicweb order object:
PaymentCode
ShippingCode
ShippingAgentCode

ShippingAgentServiceCode

Those fields will be made as translatable per the needed langauge when editing the Payment/Shipping:
PaymentTermsDescription, ShippingAgentName, ShippingAgentServiceDescription

Here is the sceen when you are creating the Sales order in BC where those fields are available:


So let us know if those fields are OK for you or if you have any other comments/suggestions.

Kind regards, Dmitrij
 
Nuno Aguiar Dynamicweb Employee
Nuno Aguiar
Reply

Hi Dmitriy,

 

They are OK from my point of view. I asked some of my team members that deal with this to chime in as well as they might have additional insight.

 

BR

Nuno

 
Scott Forsyth Dynamicweb Employee
Scott Forsyth
Reply

Hi Dmitriy,

I'm pleased to see you considering this feature. It's very valuable to myself, and, I see, many others on this thread.

What about supporting custom fields rather than a set of fixed values? That makes it more flexible for future needs. The requirements aren't too difficult because I don't see a need for a dropdown list, or other complex fields. Just a string, and maybe a long string would make me happy. Others can speak up if there are more needs. 

We find that each ERP has slightly different needs, and the names are slightly different too. So, it would be valuable to be able to create our own rather than having a pre-defined list. And, it should use the EcomProducts or EcomOrders style, and definitely not the EcomOrderLines (XML based). 

Note that Live Integration will also need to be updated to include those values in the order request. They don't need to be stored in EcomOrders. They should be for read-only lookup only using a join.

It should be for at least the Shipping and Payment provider, but it may not hurt to do the tax provider to be consistent.

Hope I didn't make this seem too scary, but this would have years of good life to have custom fields on the 3 providers.

Thanks,

Scott

 
Imar Spaanjaars Dynamicweb Employee
Imar Spaanjaars
Reply

+1 to the custom fields. For shippers, we often have additional requirements like "Ships on pallet", "Ships on ice" and a bunch more that we coud handle with custom fields. I'd say not only textboxes, but other controls too.

Imar

 

You must be logged in to post in the forum