Freight Rule Group

Regional identifiyer

Must be a valid regional;

No

Name of the freigth rule group

When executing this operation, only the group shipping rules provided in this field will be valid; this field must receive a valid freight group in the TOL;

The freightRuleGroup field can receive any useful value for the business. This field is only for grouping the shipping rules from some business perspective.
Important points about this field:

- The initial date of validity of the shipping rules are always associated with a shipping group;
- To update the shipping rules in the TOL, it will always be necessary to inform the shipping group associated with these rules;
- The update of the freight rules of the same group, in fact, will replace all the freight rules that had the same initial validity date (validityInitialDate) controlled in this interface;

Example:
- A particular customer could create a single freight group for all of Brazil or could create a freight group for each of its plants; in the case of this last hypothetical scenario, if a company has 3 plants (for example, 1 in Rio de Janeiro, 1 in São Paulo and 1 in Pernambuco) it could define 3 freight groups (in the case of the example, these groups could be called from ""PE Shipping Rules"", ""SP Shipping Rules"" and ""RJ Shipping Rules""); In this scenario, if a single freight rule for a given carrier in Rio de Janeiro was changed in the external system (in the example, let's use it as FR1) and you wanted this rule (i.e. FR1) to be updated in the TOL, the external system must send the updated rule (that is, FR1) and all other freight rules from the group ""Freight Rules RJ"" to the TOL on this interface; if the other rules of the group ""Freight Rules RJ"" were not also sent, the TOL would consider that the group ""Freight Rules RJ"" was modified to contain only the updated freight rule (i.e., FR1), which, of course, is not what is wanted;

Date/time of the vigenci the freigth rule group

Group shipping rules will only be effective after the date/time provided in this field; if the effective date received in this field does not exist for a given group, it will be created;
Example scenarios for the upgrade scenario:

• If shipping rules were sent yesterday with a start date in the future (example: 05/07/YYYY) and today you want to update these rules, you must send the updated freight rules with the same start date sent previously ( in the example, 7/5/YYYY);

• If shipping rules are sent this morning with today's start date (05/06/YYYY) and updates to these same rules are sent this afternoon, you must send the updated shipping rules with the same start date sent previously (in the example, 05/06/YYYY); in this scenario, from the morning until the afternoon (even before receiving the updated shipping rules) the TOL will use the originally received rules (in this example, the rules received this morning);

• If 30 days ago (example: 06/05/YYYY) shipping rules are sent with a start date last week (example: 29/05/YYYY) and today (05/06/YYYY) updates are sent to these rules rules, you must submit the updated shipping rules with today's start date (06/05/YYYY); in this scenario, between 5/29/YYYY and 6/5/YYYY (even before the updated shipping rules are received) TOL will use the originally received rules (in this example, the rules received 5/6/YYYY);

Note that if TOL  receives shipping rules with start dates already in the past, an error message will be returned and no updates will be made."

Grouping element of all freight rules

This field must have a valid transport zone ID in the TOL;
The originCarrierZoneSourceId/destinationCarrierZoneSourceId fields can be any “transport zones” previously registered in the TOL (note that these fields are just zone IDs already existing in the TOL).
The important point is that these zones must be relevant to the freight calculation process.
For this interface to work, all zones sent on this interface must have been previously and correctly configured in the TOL so that the TOL can identify them from the IDs sent by the external system in the originCarrierZoneSourceId/destinationCarrierZoneSourceId fields.

For example:
If the freight table has a simple freight rule of the type “Transport orders from origin O to destination zone Z have a freight value V”, it is necessary that this zone Z exists in the TOL and that its geographic coverage in the TOL is correct for the calculation of the freight value V.
In addition, zone Z in the TOL must be associated with a code that the external system knows (example: “123”).
Every time the external system needs to reference zone Z in the TOL, this code (in the example, “123”) must be sent by the external system to the TOL in the freight interface (in the previous example, the interface should send “123” in the destinationCarrierZoneSourceId field for Z zone reference).
The ideal scenario is that all zones in the external system are related to “transport zones” in the TOL in such a way that each of them has the respective ID of the equivalent zones in the external system (this is useful to avoid translation tables of IDs in the external system external).

Grouping element of all results