# Omnichannel registratie **Auteur**: Joeri Diederen | **Status**: In voorbereiding ## Randvoorwaarden Deze registratiemethode gaat uit van processen die worden afgehandeld met componenten die voldoen aan de Common Ground richtlijnen. {% hint style="info" %} Registratiemethode bij een product vastleggen in Open Product. Verzoekenpatroon, StUF, etc. {% endhint %} ## Uitgangspunten Er wordt een object gecreerd dat als gegevensdrager fungeert. De creatie of update van het object leidt tot een notificatie aan het systeem dat de inhoud verwerkt. Voordeel hiervan is dat de uiteindelijke registratie flexibel in te richten is. Uitgangspunten hierbij zijn: * Een nieuwe aanvraag leidt altijd tot een *verzoekobject* * Bij aanvulling op verzoek van de behandelaar wordt de *externe taak* gebruikt * Een opmerking op een lopende zaak leidt tot een *zaakverzoek* {% hint style="warning" %} Expliciet gevolg hiervan is dat bij een verzoek om aanvulling altijd een *externe taak* wordt aangemaakt, ongeacht via welk kanaal je die aanvulling verwacht.\ \ Optioneel kan een bericht worden samengesteld dat digitaal gepubliceerd word op het portaal, of per post verzonden wordt. Bij fysieke verzending van dit bericht is de best practice om een verwijzing naar de externe taak op te nemen, zodat de klant effectief, digitaal en veilig de aanvulling kan leveren. {% endhint %}

Grafische weergave van de uitgangspunten

## Nadere uitwerking ### Use case 1: Informatie als verzoek voor een zaak Voor informatie die leidt tot een nieuwe zaak wordt gestuurd op verwerking via het verzoekobject. Bijlagen worden via de DRC-API geregistreerd, en het unieke kenmerk van de bijlage wordt verwerkt in het verzoekobject. Door het lezen van het verzoekobjecttype kan de gewenste informatie om het verzoek te leveren door scan- en herkenfunctionaliteit verwerkt worden in het verzoekobject, liefst met scan- en herkenfunctionaliteit, wat de afhandeltermijn ten goede komt. Via het bestaande patroon wordt het juiste afhandelcomponent genotificeerd, waarna het verzoek tot zaak verwerkt kan worden.

Van verzoek tot registratie.

### Use case 2: Informatie als aanvulling In deze use case zijn twee opties mogelijk. De behandelaar heeft een verzoek om aanvulling gedaan, of de initiator besluit op eigen initiatief om iets na te leveren. #### Externe taak Als de behandelaar een verzoek om aanvulling heeft gedaan staat er een externe taak in de Taken API (conceptnaam). Het patroon schrijft voor dat binnenkomende informatie, ongeacht kanaal, als update op deze externe taak wordt gedaan.

Een verzoek om aanvulling die via een externe taak geregistreerd wordt

#### Zaakverzoek Als de klant zelf besluit om iets na te leveren, wellicht omdat er optionele taken klaarstaan op het portaal, wordt het zaakverzoek gebruikt. Een ingediend zaakverzoek is voor de zaakbehandelaar een ad-hoc event waarop het proces moet acteren: er moet informatie beoordeeld worden.

Een nalevering die als zaakverzoek geregistreerd wordt

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://dienstverleningsplatform.gitbook.io/platform-generieke-dienstverlening-public/onderzoeken/omnichannel-registratie.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.