Estimated Value - Currency Field missiong in notice-type - 4.json

[ankoens]

I want to ask why inside of GR-Procedure-Score for BT-27-Procedure the field currency does not exist. In enotice2 preview there is a currency field (see Attachment - EstimatedValue).

[YvesJo]

HI,
Thanks for sharing your question.
Estimated Value (BT-27-Procedure) is, as specified in fields.json, a field of type amount. There is an implicit rule according to which an amount has to be specified together with its Currency. The currency is encoded in the XML using the currencyID attribute of the element associated to the field.
KR.

[ankoens]

Thanks for you answer.

We would need some more help please.
We are not using SDK, as we are implementing eForms using .NET. This makes implementation for us difficult.
We need to manually read and understand the rules from the SDK and try to implement them in our own system.

Please help us with the following questions:

1. Is the folder structure under https://github.com/OP-TED/eForms-SDK/tree/develop/notice-types representing all fields, which need to be implemented per notice type into one form? (one json = one notice type)

2. If Yes, then why (see screenshot above) is the field "currency" not present in the json file in the same way as the information under "BT-27-procedure" (see above). Then we would see that this information needs to be implemented as a textbox. In the case of "currency", there is no information in the json that it needs to be implemented as a dropdown.

3. Concerning the specification of „BT-27-Procedure“, we can not find relevant rules in fields.js (see screenshot below). Now we need to check every field manually in XML Examples, if there are any connections with this field (ie. „Currency“). This takes a lot of time. Is it possible to update the specification (for example: notice type json files with all fields), so that it is readable for eSenders which implement eForms without SDK (in existing -NET apllication).

[YvesJo]

1. There is indeed one file per notice subtype.
2. Any field of type amount requires not only a figure but also an associated currency. For the figures, textboxes are certainly the best options, for currency you may go for whatever you consider the best. On the provided screenshot, for currency, the option relies on a text box that helps filter the options of the currency codelist as the user is encoding information. Any other option is possible, just find the most suitable for you and your users.
3. There is no specific rule on currency applied, some checks may however be required prior to do some operations/comparison to ensure amounts are expressed using a same currency.

[rousso]

Hi @ankoens,

My reply will focus on this phrase from your question:

We are not using SDK, as we are implementing eForms using .NET. This makes implementation for us difficult. We need to manually read and understand the rules from the SDK and try to implement them in our own system.

What are the difficulties you are facing in your .NET implementation? You do not "need" to read and understand the rules and try to implement them manually.

The SDK is platform independent. It is comprised only of text files which you can read with any programming language. I do not think that there is any amount of help you can get that will allow you to follow 780 fields and 39.000 rules by reading and coding them manually.

What exactly is the problem with .NET development and the SDK? It cannot be the file formats. All the file formats we are using are open and standard (XSD, XML, JSON). The only non-standard format that is included in the SDK is EFX. However, EFX is still an open format that we introduced in order to be able to express business rules in a platform independent manner.

The only "problems" I can see in using the SDK for .NET developer are:

• It would be nice to have the SDK published with NuGet.
  This is not absolutely necessary. It is "nice to have" and it is in our plans to add NuGet (and npm and any other package manager that makes sense for eSenders).
• It would be nice to have an "EFX Toolkit for .NET".

What other problems do you face in using the SDK with .NET?
Please let us know and be specific about it. Whatever the problem is, there is definitely a solution for it that is far easier than coding and maintaining all eForms fields and rules manually.

If it is the absence of an "EFX Toolkit for .NET" that prevents you from using the SDK you have the following options:

1. Use the EFX Toolkit for Java to translate all EFX expressions at the time of downloading the SDK. EFX translation is deterministic and there is no need to translate EFX at runtime. Translate it once as soon as you download a new version of the SDK so that you application is totally independent of EFX.
2. Port the EFX Toolkit to .NET. You can do this in different ways:
   • DIY (do it yourself using as a guide and inspiration the Java implementation we already provided).
   • Check if other eSenders are creating and EFX Toolkit for .NET
   • Check if the Publications Office can provide an EFX Toolkit for .NET and in what time frame.

I want to help you "escape" from a situation where you need to process and code the rules manually.
Please let me know what exactly is preventing you from using the eForms SDK in .NET and I will make sure all the problems that can be addressed within the SDK are addressed as soon as possible.

Regards,
Yannis

[ankoens]

Hi @rousso,

thank you for your reply.

At the moment we are facing substantial problems with trying to integrate eforms into our existing .NET application and I would like to explain our situation more in detail.

We are experiencing the following difficulties:

We have our own framework for building forms and validation rules. We have built this framework and use it for the past 5 years. We have our own structure how to save data and then we export it to different formats (ie TED Forms-XML or Json).

This framework is the core of our application and it is not realistically possible to change it, because a lot of dependencies with this framework. Therefore we need to use this framework to build forms and validation rules per notice type. For us one notice type represents one form. Because of that we need to understand and follow the rules and field, which need to be included in one form.

How can we make use of the SDK/EfX-Toolkit in our situation?
How can we prevent having to code and understand alle fields/rules manually?

In the „old“-Forms we had a readable and understandable excel with a list of all the rules, fields and dependencies, which helped us with implementation into our framework. We also had PDF. with complete view of forms. We are currently trying to validate sample forms in the enotice2 preview, an also trying to import samples from SDK, but we are not successful and we are getting many validation errors. It would be helpful to get a stable version of the application, where validation and publishing of forms is possible. We also do not see the possibility of changes after publishing, or change-forms within enotice2-application.

We cannot understand how EFX-Toolkit can help-us in our situation, or how we can avoid implementing rules manually and still using our framework/rendering.

Thank you for your help, your input is very important to us in order to be able to continue with eForms implementation within the required timeframe.

Best Regards