Supplier Management

Get Involved. Join the Conversation.

Topic

    Marko Knezevic
    Review and fix the supplier creation errors
    Topic posted February 6, 2019 by Marko KnezevicBronze Medal: 1,250+ Points, last edited February 6, 2019, tagged Approvals/Notifications, How-To, Supplier Creation, Supplier Registration 
    181 Views, 11 Comments
    Title:
    Review and fix the supplier creation errors
    Summary:
    E-mail notification to Supplier if Supplier Administrator clicks "Cancel Supplier Creation" instead after Approval
    Content:

    Hello,

    I have a problem with notifications to the Supplier after the process ends with Cancel Supplier Creation.

    Manage Supplier Registration Approvals only first stage enabled:

    • Action Type Approval required
    • Route Using Single Approver
    • User Type Supplier Administrators

    Steps that describe the problem:

    1. Supplier goes to Prospective Supplier Registration URL, enters all the data and clicks Submit
    2. Suppler Administrator is notified and clicks the notification to see the Registration
    3. Supplier Administrator Approves the Registration
    4. Supplier is notifed by e-mail that his company is now our Supplier
    5. The Supplier is not yet created since there are errors (Tax Account Number already exists)
    6. Supplier Administrator clicks the Cancel Supplier Creation button (on purpose or by mistake) and the registration process is now canceled
    7. The Supplier is not notified by e-mail that he in fact is not a registered supplier for our company!

    How to:

    1. Disable the e-mail notification to the Supplier after Supplier Registration Approval
    2. Only enable the e-mail notification to the Supplier after sucessful Supplier Registration and Creation (Supplier Creation Status = Created)

    Thank you,
    Best regards.

    Marko

    Comment

     

    • Piyush Singh

      Hi Marko,

      If an incorrect/duplicate tax information is identified, the admin can:

      1. Edit the data after cross verifying with the requester and complete the supplier creation, or

      2. Cancel the supplier creation if there is a genuine duplicate is identified.

      If you edit the registration data and create the supplier, the earlier notification sent should not be a concern. If the decision is to cancel the supplier creation, then you may not want to notify the requester that you have canceled because the supplier with given tax information already exists in the application. This could actually cause data integrity issue.

      Hope this answers your question.

      Thanks,

      Piyush

    • Marko Knezevic

      Hello Piyush,

      first of all, thank you for your response.

      I am aware of the things you have written, however I still don't agree that any notification should be sent to outside user before the data validation and approvals are made. The notification that the Supplier is approved most definitely shouldn't be the last one in case approvers decide to cancel the supplier creation.

      Do you know if there is a way for me to set things up in this order:

      1. Data Validation
      2. Approval
      3. Supplier User Notification

      Best regards,

      Marko

    • Piyush Singh

      Hi Marko,

      We will need to understand more on what your business is facing. Please help answer following questions:

      1. How often do you get registration requests that error due to duplicate tax information?

      2. Are these genuine duplicates (supplier already exists) or requester entered incorrect information?

      Thanks,

      Piyush

      • Marko Knezevic

        Hi Piyush,

        Thank you for your engagement in this case. Just to set things up properly I would like to explain the situation better.

        We are implementnig Cloud Sourcing for a client who has EBS (where he already has the Current Suppliers registered).

        We have the following case with our client during Cloud Procurement Sourcing implementation with Supplier Registration.

        The client requirements for Supplier Registration are: 

        • all Current Suppliers to be registered again via Spend Authorized URL 
        • new potential suppliers to be registered via Prospective URL
        • one click Approval for both business relationships

        In the meantime, I have solved the part of the problem by changing the Registration Approval setup.

        The Supplier Registration Approvals were earlier (when I started the topic) set up like this:

        Supplier Registration Approval (Stage one only)

        • If Prospective => approvers are Supplier Administators
        • If Spend Authorized => AutoApproved

        Spend Authorized Approval

        • Approvers are Supplier Managers

        This first setup was not good because the Supplier User was created before Error validation and he got notified by e-mail with password registration link which was not valid if the outcome of „Review and fix the supplier creation errors“ = Cancel Supplier Creattion.

        New Approval setup:

        Supplier Registration Approval (Stage one only)

        • If Prospective => approvers are Supplier Administators
        • If Spend Authorized => approvers are Supplier Managers

        Spend Authorized Approval

        • AutoApproved

        Now the problem with Supplier User welcome and reset password URL is eliminated, since he does not receive it until the Supplier is proprely created – the outcome of „Review and fix the supplier creation errors“ = Create Supplier.

        However, there is still a problem with the first e-mail notification: „Supplier Registration Request XXXX Was Approved". I would like to eliminate this notification since this is really not relevant to the Supplier, he basically only needs to know the final outcome – is he a supplier or not.

        Can you help me achieve this?

        Another question, perhaps for a new topic, but… :

        I have seen that 19A has the Tax Registration Number, Taxpayer ID and D-U-N-S frontend validation now (which is great - haven't tested it yet), but I still think that the notifications should be sent after the System Validation has passed succesfully.

        Regarding the mentioned frontend validation (Tax Registration Number, Taxpayer ID and D-U-N-S), what happens if:

        • one supplier enters his data to Tax Registration Number and registers
        • another enters the exact same data to Taxpayer ID and registers 
        • third one enters the exact same data to D-U-N-S and registers? 

        Will the system Data Validation check this case or not? 
        Does the Validation compare the entry from Taxpayer ID to already registered Suppliers numbers on Tax Registration Number and D-U-N-S or not?

        We had a case earlier where one supplier entered the number to Taxpayer ID and another entered the same nubmer to Tax Registration Number and they were both registered as different suppliers (but in fact were the same company)...

        Thank you,
        Best regards

        • Piyush Singh

          Hi Marko,

          The validations on duplicate is not across attributes i.e. duplicate for TRN will be validated only against existing TRNs and not against D-U-N-S number and Taxpayer ID.

          Regarding the notification to be sent after the supplier is created, please go ahead and share that as an idea and we will evaluate it further.

          Do let us know if you still have any question unanswered.

          Thanks,

          Piyush

          • Marko Knezevic

            Hello Piyush,

            another issue I have is with Bank Account, where IBAN is not verified against Bank Account number but only the country specific validation is done.

            IBAN contains the Bank Account number, but the system does not validate that Bank Account number is the same as the one contained in IBAN field. 

            So the supplier can currently enter like this for example (the system will validate the registration as ok if Bank Account is not duplicate):

            IBAN = HR810299804 8909239156

            bank account number = 1234567890

            where in fact this is not ok. If we assume that IBAN is correct in this example, then bank account number should be 8909239156 (last 10 IBAN digits).

            is there any indication that this will be corrected in the near future?

            Thank you again.

            • Piyush Singh

              Hi Marko,

              Please note, bank account number is considered for payments and therefore it gets priority over IBAN. Given that account number is a required attribute, it becomes significant for users to ensure they provide correct account number when creating a bank account.

              But your use case is valid and we do have a solution for this on our roadmap.

              Thanks,

              Piyush

    • Jim Van Tongerloo

      Hi Marko, Piyush,

      I've witnessed the exact same problem.

      Due to data validation not happening in the Supplier Registration form (there is an Enhancement Request for this), populating these fields will always be very prone to error (extra spaces, points, no country code,..).

      On top, using single sign on, the email notifications have been turned off completely. Meaning after a supplier contact is created by the system, we have to manually reset the User Category to a different one than the default, to get notifications out.

      This entire process works, but is very slow. Certainly if you want to use it in combination with Sourcing and public tenders (where a supplier first needs to register and get a user account).

      Jim

    • Piyush Singh

      Hi Jim,

      You are referring to data validations not happening in registration form. May I know what data validations are you referring to?

      Thanks,

      Piyush

      • Jim Van Tongerloo

        Hi Piyush,

        The Tax Registration Number (VAT Number).
        This has a specific format for every country and when creating a supplier manually in Supplier Module, this field will be validated against the proper format.

        However, on the Supplier Registration form for the Supplier to fill out, these data validations are not done.
        So he is able to submit his registration with a complete wrong number.

        This will result in the Registration being submitted, auto approved (if no approvals behind the form) and then failing at supplier creation because at that point, the validation is done.

        This is reverse logic, in my opinion. Perform the data validation on the Supplier Registration form for when the Supplier fills it in. The validations are present and already being used for internal supplier creation. I don't see a reason why we need this mismatch and basically make this process not workable.

        I refer to the following BUG:
        Bug 26637591 : REGISTER SUPPLIER : ALLOW TAX REGISTRATION NUMBER FORMAT VALIDATION

        And I refer to multiple (duplicate) requests on this forum by Clients:
        https://cloudcustomerconnect.oracle.com/posts/4c9b4457ff
        https://cloudcustomerconnect.oracle.com/posts/5303595664
        https://cloudcustomerconnect.oracle.com/posts/9962a44852

        This is a very simple requirement and I hope Oracle can include it very soon.

        Jim

         

         

    • Piyush Singh

      Hi Jim,

      Yes, this is on the agenda, you can go ahead and vote for the idea and share your feedback.

      You have concerns only with the TRN format validation, right?

      Thanks,

      Piyush