Developer forum

Hi Arnor

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

BR Nicolai

+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

@Nuno - sounds a bit implementation specific.

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

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

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

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

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

+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

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

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

+1 for this feature request

+1 from me too

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:

 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

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

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

+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

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.

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

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

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

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

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

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

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

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

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

Thanks Dmitrij!

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

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

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