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
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
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

 
Dmitriy Benyuk 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

 
Martin Moen
Reply

I can see that this is now implemented, and the fields are available on the shipping method in the administration.
However the shipping method agent code (and the other fields from above) is not filled out in the order xml.

I have created the fields in "Order fields" (see attachment) but still they are not autmatically filled out.
Do I have to do anything in the frontend templates to make it work?

We are using DW 9.12.5 with these ecommerce dll's.

Dynamicweb.Ecommerce.dll 1.12.33
Dynamicweb.Ecommerce, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Build date Wed, 15 Dec 2021 20:18
Dynamicweb.Ecommerce.DynamicwebLiveIntegration.dll 6.1.1
Dynamicweb.Ecommerce.DynamicwebLiveIntegration, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Build date Wed, 15 Dec 2021 20:18
Screenshot_2021-12-20_113813.png
 
Martin Moen
Reply

Okay, I see that it might be handled in a different way by the integration.
Can see that it is set here:

 
Lars Hejgaard Sørensen Dynamicweb Employee
Lars Hejgaard Sørensen
Reply
This post has been marked as an answer

Hi Martin,

I checked up on the code, and it the information is not included in the XML request. I'll ask the PM to consider that.

If you want the information added to the custom fields, you'll have to add hidden fields with the appropriate field names and the values set to the shipping tags accordingly, e.g.:

That will include it in the XML sent to the ERP system:

Please note that the codeunit only detects if shipping charges should be added, and if so, adds an item charge line on the order, so you would need to extend the codeunit to add these information to the sales header. Let me know, if you need any help on that 😊

Br.

Lars

Votes for this answer: 1
 
Tomas Gomez
Reply

Hi,

The XML of our solution doesn't include these data neither (DW 9.13.7, Swift 1.6)

Are they already added and I miss something? Are they sent by LiveIntegration? or, as Lars says, is it needed to add these data in the templates and extend the codeunit?

Regards,
Tomas

 
Tomas Gomez
Reply

Hi again,

I send the configuration both in DW and BC.

About Payment methods, I try to settup a Paypal method. The definitions in BC are

  

So the settings in DW for the Paypal method has Code = PAYPAL

The order in DW displays PAYPAL as the pyment method (despite it doesn't appear in the order XML)

But the Payment code in BC is empty

Does somebody knows what am I missing?

Regards,
Tomas

 

 
Dmitriy Benyuk Dynamicweb Employee
Dmitriy Benyuk
Reply

Hi Tomas,
the fields: OrderShippingCode, OrderShippingAgentCode, OrderShippingAgentName, OrderShippingAgentServiceCode, OrderShippingAgentServiceDescription are not yet
included in the Live integration but they would be in future, so for now you can use this subscriber code that will send this information in the Live integration request xml,
see attached source code for that.
BR, Dmitrij

 
Dmitriy Benyuk Dynamicweb Employee
Dmitriy Benyuk
Reply

Hi Tomas,
the codeunit is not setting the payment method on the sales order in BC, but you can use the extensibility points to set it.
Look into DynamicwebOrdersPublisher codeunit and subscribe to OnBeforeUpdateSalesHeader event to set the fields you need on the sales header.
BR, Dmitrij

 
Tomas Gomez
Reply

Hi Dmitrij,

Thanks for the help and Ok about the shippment data.

At this moment we need only the payment data, as all the orders in BC arrive with empty data for the payment method.

Are the payment data implemented? (Payment method Code, Terms Code, and Terms)

If it is not implemented yet, which is the best option?
- To implement an OrderAfterGenerateXmlSubscriber (your link is broken, could you send it again?)
- (As seen above by Martin & Lars) To add custom order fields and modify the template (which template would be in Swift?)

Regards,
Tomas

 

 
Tomas Gomez
Reply

Ooops, we are replying ourselves simultaneously :-)

So I understand that it is also needed to extend the codeunit, but in the documentation appears some mapping of the PaymentMethod to Bc
https://doc.dynamicweb.com/documentation-9/integration/integration-framework/erp-plug-in-units/365-business-central-code-unit-mappings#sideNavTitle1-1-29

Is it possible to get the payment method without extending the codeunit? Is there any oher task?

Regards
Tomas

 

 
Dmitriy Benyuk Dynamicweb Employee
Dmitriy Benyuk
Reply

No, it is not implemented for the creating order request, it is only available for the Integration customer center orders lists/order details.
So you need to use the subscriber I mentioned in the previous post and set the fields by your code instead

 
Tomas Gomez
Reply

Hi Dmitrij,

Thanks for the confirmation.

One last question: Is it needed to implement the OrderAfterGenerateXmlSubscriber.cs? or could it be done by setting new custom Order fields? (in Settings > Ecom > Orders > Order fields)

Setting new order fields looks cleaner and easier to update/modify. Is there any difference between both methods?

Regards,
Tomas

 

 

 
Dmitriy Benyuk Dynamicweb Employee
Dmitriy Benyuk
Reply
This post has been marked as an answer

Hi Tomas,
both variants are possible, so it is up to you. Using custom subscriber gives more fexibility, so you can append the fields when needed and not always,
for example only when Dynamicweb handles the shipping.
Here is a source code from the attached file that was attached in the previous post:
 

using Dynamicweb.Extensibility.Notifications;
using Dynamicweb.Ecommerce.DynamicwebLiveIntegration.Notifications;
using Dynamicweb.Ecommerce.DynamicwebLiveIntegration.Configuration;
using System.Xml;
namespace Dynamicweb.Ecommerce.DynamicwebLiveIntegration.Examples.Notifications
{
    /// <summary>
    /// Class OrderAfterGenerateXmlSubscriber.
    /// </summary>
    /// <seealso cref="NotificationSubscriber" />
    [Subscribe(Order.OnAfterGenerateOrderXml)]
    public class OrderAfterGenerateXmlSubscriber : NotificationSubscriber
    {        
        public override void OnNotify(string notification, NotificationArgs args)
        {
            var myArgs = (Order.OnAfterGenerateOrderXmlArgs)args;
            if (myArgs?.Document != null)
            {
                var settings = SettingsManager.CurrentSettings;
                if (!settings.ErpControlsShipping)
                {
                    var order =  myArgs.Order;
                    var shipping = Services.Shippings.GetShipping(order.ShippingMethodId);
                    if (shipping != null)
                    {
                        var itemNode = myArgs.Document.SelectSingleNode("//item [@table='EcomOrders']");
                        if (itemNode != null)
                        {
                            AddChildXmlNode(itemNode, "OrderShippingCode", shipping.Code);
                            AddChildXmlNode(itemNode, "OrderShippingAgentCode", shipping.AgentCode);
                            AddChildXmlNode(itemNode, "OrderShippingAgentName", shipping.GetAgentName(order.LanguageId));
                            AddChildXmlNode(itemNode, "OrderShippingAgentServiceCode", shipping.AgentServiceCode);
                            AddChildXmlNode(itemNode, "OrderShippingAgentServiceDescription", shipping.GetAgentServiceDescription(order.LanguageId));
                        }
                    }
                }
            }
        }

        private void AddChildXmlNode(XmlNode parent, string nodeName, string nodeValue)
        {
            var node = parent.OwnerDocument.CreateElement("column");
            node.SetAttribute("columnName", nodeName);
            node.InnerText = nodeValue;
            parent.AppendChild(node);
        }
    }
}
BR, Dmitrij

Votes for this answer: 1
 
Tomas Gomez
Reply

Thanks Dmitrij!

 
John Cristian Villamar Cueva
Reply

Hello Dimitrij, the code you attached is no longer available, I am working with Tomas on this issue, please can you share it again.

Thanks.

JVC

 
Tomas Gomez
Reply

Hi Dmitrij,

We succesfully implemented the extra parameters in the XML. John Criistian is working on extending the codeunit to integrate the parameteres in BC.

Do you have any sample code of a codeunit extension using the DynamicwebOrdersPublisher and the OnBeforeUpdateSalesHeader? We use an OnPrem BC14.

Regards,
Tomas

 
Dmitriy Benyuk Dynamicweb Employee
Dmitriy Benyuk
Reply

Hi Tomas,
yes, the examples are all present in this sample solution that is available for download on the doc site here. Just search for "OnBeforeUpdateSalesHeader" text in the sources.
BR, Dmitrij

 

You must be logged in to post in the forum