CustomerGate 365: naslag webservices

De services

CustomerGate 365 publiceert acht webservices. De app publiceert ze zelf bij de installatie en bij elke update: een ontbrekende service wordt aangemaakt, en een service die onder die naam al bestaat, wordt nooit gewijzigd, ook niet als iemand hem met de hand heeft ongepubliceerd of aangepast. De drie services van iFacto bestaan alleen waar Steel 365 geïnstalleerd is.

Aanmelden

De website praat met Business Central als twee Microsoft Entra-toepassingen. Hun client-ID's staan op CustomerGate-instellingen, en Machtigingen herstellen registreert ze daar in Business Central en wijst hun machtigingssets toe.

Geen van beide toepassingen kan de services van de ander gebruiken: de websitetoepassing heeft geen uitvoerrecht op de cataloguspagina's, en de synchronisatietoepassing geen op voaPortal of voaRequests.

Machtigingssets

Een token ophalen

Beide toepassingen gebruiken de OAuth 2.0-clientreferentiestroom:

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

grant_type=client_credentials
client_id={client id}
client_secret={secret}
scope=https://api.businesscentral.dynamics.com/.default

Stuur het toegangstoken bij elke aanroep mee als Authorization: Bearer {token}.

Endpoints en afspraken

Alle services zijn standaard OData v4-endpoints van Business Central onder https://api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/ODataV4.

Paginaservices

De cataloguspagina's leest u met GET. De referentiewebsite spreekt het bedrijf op naam aan:

GET .../ODataV4/Company('{company name}')/voaItems?$select=No,Description&$filter=...

Een bedrijfsnaam met een apostrof krijgt die dubbel (O''Brien), zoals OData voorschrijft. Grote resultaten komen in pagina's: volg @odata.nextLink tot die er niet meer is. De records staan in value.

Codeunitservices

voaRequests en voaPortal bieden elke openbare procedure aan als unbound action met de naam {service}_{Procedure}. Roep die aan met POST en geef de parameters op naam mee in een JSON-body. De referentiewebsite spreekt het bedrijf aan met zijn GUID, de id van het bedrijf in de standaard companies-API:

POST https://api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/ODataV4/voaPortal_ReadSession?company={company id}
Authorization: Bearer {access token}
Content-Type: application/json
Accept: application/json
Accept-Language: en-US

{"token": "<session token>"}

De teruggave komt in de OData-envelop onder value:

{"@odata.context": "…", "value": "{\"email\":\"buyer@example.com\",\"customerNo\":\"C00010\", …}"}

Afspraken

• Namen zijn hoofdlettergevoelig en worden op naam gebonden. voaPortal_readSession bestaat niet, en een parameter die emailAddress heet in plaats van email levert een 400 op zonder verdere uitleg.
• Elke parameter is een tekenreeks: alle procedureparameters zijn AL-Text.
• Een JSON-resultaat komt terug als tekenreeks binnen value, omdat een unbound action geen genest object kan teruggeven. Ontleed value een tweede keer. Een booleaanse uitkomst is een JSON-true of false in value.
• Een lege tekenreeks is een antwoord. Bij de meeste procedures van voaPortal betekent "": geen geldige sessie, of hier is niets voor u.
• Optionele sleutels worden weggelaten, niet als null verstuurd. Behandel een ontbrekende sleutel als null.
• Datums zijn YYYY-MM-DD, tijdstempels zijn ISO 8601 in UTC (2026-09-19T14:30:00.000Z). Een lege datum of tijdstempel is "".
• Getallen en booleans zijn JSON-getallen en JSON-booleans.
• Accept-Language bepaalt de taal van de Business Central-sessie. Dat raakt foutmeldingen en de optiebijschriften in de catalogus, nooit de vaste waarden hieronder. De referentiewebsite stuurt nl-NL.

Statuscodes en opnieuw proberen

Na een 429 opnieuw proberen kan altijd. Na een netwerkfout, een time-out, een 409 of een 5xx probeert u alleen de lezende procedures opnieuw (ReadSession, MyDetails, MyDeliveryAddresses, MyRequests, MyQuotes, MyOrders, MyShipments, DocumentLines, MyDocuments, Document). Probeer RequestCode, SignIn, SignOut, LinkRequest en AcceptQuote niet uit uzelf opnieuw; bij CreateQuoteRequest en CreateAccountRequest is opnieuw proberen alleen veilig met dezelfde requestId.

Het beveiligingsmodel

Er zijn twee lagen. De Entra-toepassing bewijst dat de aanroeper de website is; ze wijst nooit een klant aan. Het sessietoken van het portaal wijst de aangemelde persoon aan, en Business Central leidt daar de klant uit af. Het klantnummer reist nooit van de website naar Business Central: geen enkele procedure neemt een klantnummer, een e-mailfilter of een andere parameter aan die bepaalt wiens gegevens er terugkomen.

Portaalgebruikers

• Iemand mag het portaal gebruiken zodra de binnendienst zijn accountaanvraag heeft goedgekeurd. Daarmee ontstaat een portaalgebruiker: een e-mailadres gekoppeld aan één klant, met een rol. De website kan geen portaalgebruikers aanmaken.
• E-mailadressen worden in kleine letters vergeleken, zonder spaties eromheen.
• Is één adres aan meer klanten gekoppeld, dan krijgt de sessie het laagste klantnummer dat in het portaal mag. De interface kan klanten niet opsommen of wisselen.
• De portaalgebruiker moet actief en niet geanonimiseerd zijn, en de klant moet bestaan, niet voor privacy geblokkeerd zijn en niet volledig geblokkeerd. Klanten die alleen voor verzenden of factureren geblokkeerd zijn, houden toegang.

Aanmelden met een eenmalige code

1. De bezoeker vult zijn e-mailadres in; de website roept RequestCode(email, ipHash) aan.
2. Business Central maakt een code, bewaart daar alleen een gezouten hash van en mailt de code naar het adres als het bij een actieve portaalgebruiker hoort.
3. De bezoeker vult de code in; de website roept SignIn(email, code, ipHash) aan en krijgt een sessietoken, of "".
4. De website bewaart het token, bijvoorbeeld in een HttpOnly-cookie, en geeft het als token mee aan elke andere procedure van voaPortal.
5. SignOut(token) beëindigt de sessie.

De code bestaat uit tien tekens uit het alfabet 0123456789ABCDEFGHJKMNPQRSTVWXYZ (geen I, L, O of U) en staat in de e-mail als twee groepen van vijf met een koppelteken. Voor de vergelijking wordt hij genormaliseerd: spaties en koppeltekens weg, hoofdletters, O gelezen als 0, I en L als 1. Pas dezelfde regels toe als u de invoer op de website controleert.

• Een code is geldig gedurende Geldigheid aanmeldcode (min.), standaard 15 minuten, en werkt één keer. Na een geslaagde aanmelding verlopen alle andere open codes voor dat adres.
• Fout gokken sluit niemand buiten. Foute pogingen worden geteld op de nieuwste open code, tot Maximum codepogingen, als spoor om misbruik te herkennen.
• Er kunnen meer codes tegelijk leven: een nieuwe code maakt eerdere niet ongeldig.
• RequestCode antwoordt altijd true, of het adres nu bekend, gekoppeld of geblokkeerd is of de mail mislukte, en duurt altijd minstens 1,5 seconde. Zo verklapt het endpoint niemand welke adressen klant zijn.
• Tussen twee codes voor hetzelfde adres geldt een minimale wachttijd van Wachttijd aanmeldcode (sec.), standaard 60 seconden. Een verzoek binnen die tijd krijgt true en doet niets.
• De mail met de code gaat meteen vanuit de aanroep van RequestCode weg, niet via de taakwachtrij, in de taal van de accountaanvraag waar de portaalgebruiker uit voortkwam, anders de taal van de klant, anders de taal van de binnendienst.

Sessietokens

• Een token bestaat uit 64 tekens, twee GUID's als hoofdletterhex. Behandel het als ondoorzichtig; Business Central bewaart alleen de SHA-256-hash ervan. Spaties voor en na token worden genegeerd.
• Schuivende vervaltijd: een sessie verloopt na Sessieduur (min.), standaard 480, zonder gebruik. Elke geslaagde aanroep verlengt hem, hooguit één keer per minuut weggeschreven, dus een sessie kan tot een minuut eerder eindigen dan de genoemde tijd.
• Absolute grens: geen sessie leeft langer dan Maximale sessieleeftijd (uren), standaard 168, na het aanmelden, hoe actief hij ook wordt gebruikt.
• Bij elke aanroep wordt gecontroleerd of het token bestaat, niet is ingetrokken, niet is verlopen en binnen de maximale leeftijd valt, of de portaalgebruiker nog bestaat en actief is, en of de klant nog in het portaal mag. Faalt de controle op de portaalgebruiker of de klant, dan wordt de sessie meteen ingetrokken.
• De rol wordt bij elke aanroep van de portaalgebruiker gelezen, niet uit de sessie, dus een wijziging van Inkoper naar Meekijker geldt meteen.
• ReadSession geeft expiresAt terug. Gebruik dat voor de levensduur van de cookie.
• Meer aanroepen met hetzelfde token op hetzelfde moment kunnen Business Central bij één ervan 409 laten antwoorden. De lezende procedures kunt u één keer opnieuw proberen.

Het klantslot

Alles wat voaPortal teruggeeft, is gefilterd op de klant van de sessie, en geen enkele parameter kan dat filter weghalen:

Een documentnummer is een parameter in DocumentLines, Document en AcceptQuote. Het zegt wat er wordt gevraagd, nooit van wie het is. Documentnummers worden getrimd en omgezet naar hoofdletters; een nummer langer dan 20 tekens geldt als niet gevonden, niet als afgekapt.

Overal hetzelfde lege antwoord

Een document dat niet bestaat en een document van een andere klant geven precies hetzelfde antwoord. Anders zou een lijst nummers genoeg zijn om af te tasten wat er bestaat.

Rollen

Een nieuwe portaalgebruiker is Meekijker, tenzij de binnendienst Inkoper kiest, en een onbekende rolwaarde wordt gemeld als Viewer. Een Inkoper mag alles wat een Meekijker mag, plus LinkRequest, MyDeliveryAddresses en AcceptQuote. Voor een Meekijker antwoorden die drie false, "" en refused. Een Meekijker kan wel een offerteaanvraag versturen via voaRequests; die wordt dan niet aan de klant gekoppeld, en de binnendienst behandelt hem als een aanvraag van een anonieme bezoeker. MyDetails geeft role terug, zodat het formulier dat kan melden.

IP-hash

Verschillende aanroepen nemen een ipHash aan. Business Central krijgt het IP-adres van de bezoeker nooit te zien: de website rekent een hash met sleutel uit. De referentiewebsite gebruikt HMAC-SHA256 met een geheime sleutel uit haar eigen configuratie, als 64 hexadecimale tekens in kleine letters. Business Central slaat de waarde op zoals ze binnenkomt, tot 64 tekens, bij de aanmeldcode, de sessie, het akkoord op een offerte en de aanvragen, gebruikt ze alleen om misbruik te herkennen, en de opruimtaak wist ze na de bewaartermijn. Houd de sleutel geheim en stabiel: zonder sleutel is een IPv4-hash terug te rekenen.

Portaalinstellingen

Per bedrijf, op CustomerGate-instellingen:

Catalogusservices

De catalogusservices zijn alleen-lezen lijstpagina's, bedoeld voor een nachtelijke synchronisatie en niet voor live paginaweergaven. Gebruik $select om alleen de eigenschappen op te halen die u nodig hebt. De OData-eigenschapsnamen zijn de namen van de paginabesturingselementen hieronder en horen bij het contract. De waarden komen live uit de tabellen, ook de DXSteel-velden, die de app op veldnaam leest zodat hij niet van de DXSteel-app afhangt: zonder Steel 365 geeft een DXSteel-tekstveld "" terug en een DXSteel-getal 0.

voaItems

Brontabel: Artikel. Er komen geen prijzen, kosten of voorraadwaarden uit.

voaVariants

Brontabel: Artikelvariant.

voaCategories

Brontabel: Artikelcategorie, met de eigenschappen Code en Description. Er is geen veld voor de bovenliggende categorie; de referentiewebsite leidt de boom af uit de code (BALK-IPE hoort onder BALK).

voaProfiles, voaGrades, voaItemTypes

Deze drie wijzen naar pagina's van iFacto Steel 365 (DXSteel), niet naar pagina's van deze app. Hun eigenschappen liggen bij iFacto en kunnen met een update van iFacto veranderen; deze naslag legt ze niet vast. Ze bestaan alleen waar Steel 365 geïnstalleerd is.

voaRequests: offerte- en accountaanvragen

Twee acties, die elk de hele aanvraag als één tekstparameter payload met JSON aannemen en elk {"number":"…"} als tekst teruggeven. Het websiteaccount kan aanvragen aanmaken, maar ze niet teruglezen: er is geen service die aanvragen opsomt of een klant op e-mailadres opzoekt.

Hoe de payload wordt gelezen: een ontbrekende sleutel en een JSON-null betekenen allebei leeg ("", 0 of false); tekstwaarden worden stilzwijgend afgekapt op de veldlengte; Code-velden worden in hoofdletters opgeslagen; de aanroep loopt in één transactie, dus mislukt er iets, dan wordt er niets opgeslagen. Business Central zet zelf het aanvraagnummer, de status New, het tijdstip van ontvangst, de gekoppelde klant en bij accountaanvragen de beoordelaar en de reden van afwijzing; de payload doet dat nooit.

CreateQuoteRequest: sleutels in de kop

CreateQuoteRequest: sleutels per regel

Objecten in quoteRequestLines, genummerd 10000, 20000, … in de volgorde van de array:

Een voorbeeldpayload, voordat die in payload wordt geserialiseerd:

{
  "requestId": "3F2C9A1E7B0D4C5E",
  "languageCode": "NLB",
  "contactName": "Jan Example",
  "companyName": "Example Ltd",
  "email": "jan@example.com",
  "customerReference": "Site 12",
  "address": "Example Street 1",
  "postCode": "2000",
  "city": "Antwerp",
  "countryCode": "BE",
  "deliveryMethod": "Delivery",
  "useShipToAddress": true,
  "shipToName": "Example Ltd",
  "shipToAddress": "Yard Road 5",
  "shipToPostCode": "2100",
  "shipToCity": "Deurne",
  "shipToCountryCode": "BE",
  "requestedDeliveryDate": "2026-10-01",
  "remarks": "Please call before delivery.",
  "privacyAccepted": true,
  "privacyConsentVersion": "2026-09",
  "ipHash": "<64 hex characters>",
  "source": "shop/en/quote-request",
  "quoteRequestLines": [
    {
      "itemNo": "1000",
      "variantCode": "6000",
      "quantity": 4,
      "unitOfMeasureCode": "PCS",
      "lineRemarks": "Cut to 3 m"
    }
  ]
}

Wat er daarna gebeurt:

• De aanvraag komt in een eigen tabel terecht, niet in een verkoopofferte. De binnendienst zet hem met één actie om, alleen vanuit de Business Central-client.
• De mailtaak stuurt de aanvrager een bevestiging en de binnendienst een melding, afhankelijk van de schakelaars in de instellingen.
• source = counterVisit markeert een aanvraag die aan de balie is ingevoerd. Die wordt omgezet naar een verkooporder in plaats van een offerte, en er gaat geen bevestiging of melding uit. Bij afhalen krijgt de order een tekstregel met de medewerker uit assistedBy.
• Is de bezoeker aangemeld, roep dan meteen na deze aanroep LinkRequest aan om de klant van de sessie op de aanvraag te zetten. Het klantnummer zit nooit in de payload.
• shipToCode telt pas mee nadat LinkRequest hem tegen de klant van de sessie heeft gecontroleerd. Bij een aanvraag die zo niet is gekoppeld, weigert de omzetting de code tot de binnendienst hem met de hand bevestigt; stuur het adres daarom ook als tekst mee.

CreateAccountRequest

Een aanvraag voor een portaalaccount. De binnendienst koppelt hem aan een klant en een rol, of wijst hem af.

Dubbele verwerking voorkomen: requestId

Maak per formulierverzending één requestId en stuur dezelfde waarde mee als u die verzending opnieuw probeert. Een tweede aanvraag met een requestId die al bestaat, wordt geweigerd met HTTP 400, en de foutmelding bevat het merkteken [VOA-DUBBEL] en het nummer van de aanvraag die al is opgeslagen. Beschouw dat als geslaagd: de aanvraag staat in Business Central, alleen niet uit deze aanroep. De tekst van de melding wordt vertaald, dus herken het merkteken en nooit de zin. De vergelijking is in de praktijk ongevoelig voor hoofdletters, omdat de waarde in hoofdletters wordt opgeslagen; zonder requestId is er geen controle op dubbele verzendingen. De regel geldt voor beide acties, elk in de eigen tabel.

Fouten

Alle fouten zijn AL-fouten, dus de aanroep mislukt met HTTP 400 en de melding in de body. De aanvraag wordt niet opgeslagen.

voaPortal: het klantenportaal

Elke actie is POST .../ODataV4/voaPortal_{Procedure}?company={company id}. Deze vijftien procedures zijn de enige die aanroepbaar zijn; elke andere procedure in de codeunit is lokaal.

Harde grenzen

RequestCode, SignIn, SignOut

RequestCode geeft altijd true terug, na minstens 1,5 seconde; roep hem niet automatisch opnieuw aan, want elke aanroep kan een mail versturen. SignIn geeft het sessietoken van 64 tekens terug, of "" als de code verkeerd, verlopen of al gebruikt is, of als de portaalgebruiker of de klant niet meer mag; het antwoord zegt nooit welke van die gevallen het is. Een juiste code voor een gebruiker die intussen is gedeactiveerd, wordt opgebruikt en geeft "". SignOut trekt de sessie in als het token bestaat en geeft altijd true, ook bij een onbekend token; gooi de cookie hoe dan ook weg.

ReadSession

Wie er achter het token zit. Roep het aan bij elke paginaweergave van het portaal: het controleert de sessie, de portaalgebruiker en de klant, en verlengt de sessie.

MyDetails

De bedrijfsgegevens van de klant van de sessie, om het offerteformulier voor in te vullen. Elk veld is tekst en kan "" zijn. Het klantnummer zit er bewust niet in, en er zijn geen prijzen, kortingen of kredietgegevens. De sleutels zijn company, vatRegistrationNo, address, address2, postCode, city, country, phoneNo, email (het adres van de portaalgebruiker, niet dat van de klantenkaart) en role.

MyDeliveryAddresses

De geregistreerde leveradressen van de klant van de sessie, alleen voor een Inkoper: {"addresses": [{"code", "name", "address", "address2", "postCode", "city", "country"}]}, allemaal tekst. Een Meekijker krijgt "", net als bij een ongeldige sessie. Het factuuradres staat niet in deze lijst, dat staat in MyDetails. Stuur de gekozen code als shipToCode mee in CreateQuoteRequest.

LinkRequest

Zet de klant van de sessie op een offerteaanvraag die net is verstuurd, dus roep het meteen na CreateQuoteRequest aan, met dezelfde requestId. Het geeft alleen true als de sessie geldig is, de rol Inkoper is, requestId (getrimd, in hoofdletters, hooguit 64 tekens) niet leeg is, en er een offerteaanvraag met dat Verzoek-id bestaat die nog geen klant heeft. Daarna zet het de klant op de aanvraag, houdt het shipToCode alleen als dat een leveradres van die klant is en wist het anders (de adrestekst blijft staan), en zet het de Bron van de aanvraag op portal. Een false is geen fout: de aanvraag bestaat sowieso, en de binnendienst pakt hem op als elke andere.

MyRequests

De offerteaanvragen die aan de klant van de sessie zijn gekoppeld, de nieuwste eerst, hooguit 200. Geanonimiseerde aanvragen en aanvragen die als spam zijn gemarkeerd, blijven erbuiten.

MyQuotes

De verkoopoffertes van de klant van de sessie: eerst de actuele offertes, het hoogste nummer eerst, daarna offertes die alleen nog in het offertearchief bestaan (omgezet of verwijderd), alleen vrijgegeven versies, per nummer de hoogste gearchiveerde versie. Samen hooguit 100 rijen. Het antwoord is {"quotes": [ … ], "truncated": <boolean>}.

MyOrders

De verkooporders van de klant van de sessie: actuele orders, het hoogste nummer eerst, daarna orders die alleen nog in het orderarchief bestaan, per nummer de hoogste gearchiveerde versie, elke status. Samen hooguit 100 rijen, als {"orders": [ … ], "truncated": <boolean>}.

MyShipments

De geboekte verkoopverzendingen van de klant van de sessie, de nieuwste eerst, hooguit 100, als {"shipments": [ … ], "truncated": <boolean>}.

DocumentLines

Parameters: documentType is quote, order of shipment (ongevoelig voor hoofdletters; iets anders geeft ""), en documentNo is het documentnummer. Het eigendom wordt gecontroleerd voordat er ook maar één regel wordt gelezen. Bij quote en order wordt eerst het actuele document geprobeerd; bestaat dat niet, dan de hoogste versie in het archief, bij offertes alleen vrijgegeven versies. Alleen regels van het type Artikel komen terug, hooguit 500; tekst- en opmerkingsregels blijven erbuiten. Het antwoord is {"lines": [ … ]}.

Regels voor het lezen van regels: tekstsleutels van Steel 365 blijven weg als ze leeg zijn, terwijl getalsleutels van Steel 365 er zijn zodra het veld bestaat, dus 0 betekent nul en een ontbrekende sleutel betekent onbekend (toon dan een streepje, geen 0). Met Steel 365 zijn stuks, meters en kilo's drie aparte aantallen: tel ze nooit op en kies er zelf geen, unit zegt welk aantal leidend is. Openstaande en verzonden waarden bestaan alleen bij actuele orderregels; reken ze niet zelf uit. Er komt nooit een prijs, korting, marge of bedrag terug.

{
  "lines": [
    {"lineNo": 10000, "itemNo": "1000", "description": "HEA 200 S235JR", "format": "12000",
     "profile": "HEA200", "grade": "S235JR", "unit": "PCS", "quantityPieces": 4,
     "quantityMeters": 48, "quantityKg": 2035.2, "weightType": "Theoretical"}
  ]
}

AcceptQuote

Legt vast dat de klant een vrijgegeven verkoopofferte accepteert. Alleen voor een Inkoper. Er wordt in Business Central niets omgezet of vrijgegeven: het akkoord is een signaal voor de binnendienst, die de offerte met de hand omzet. Het geeft altijd een object terug met outcome (recorded, already, expired of refused) en acceptedAt (een tijdstip, of ""). De controles, op volgorde:

refused zegt nooit waarom, en already is geen fout: toon dan dat het akkoord binnen is. Probeer deze aanroep niet automatisch opnieuw. Het vastgelegde akkoord bewaart het offertenummer, de klant, het e-mailadres van de portaalgebruiker, het moment, de IP-hash, de documentdatum, het bedrag inclusief btw, de valuta, het aantal regels, de laatste archiefversie en een vingerafdruk van de regels, zodat duidelijk blijft waarmee is ingestemd als de offerte later verandert. De mailtaak stuurt daarna de klant een bevestiging en de binnendienst een melding.

MyDocuments

De pdf's die de klant van de sessie kan krijgen, als {"documents": [ … ]}, zonder truncated. De bron is er één van twee, nooit allebei: het documentarchief van Steel 365 als DXSteel Doc Archive geïnstalleerd is, anders de rapporten als Portaaldocumenten uit rapporten aan staat. Staat het archief er niet en staat die instelling uit, dan is de lijst altijd leeg. Gaat er bij het lezen van het archief iets mis, dan is de lijst leeg in plaats van een fout, en de instellingenkaart toont waarom.

Archiefrijen. Een document staat alleen in de lijst als het aan het nummer van deze klant hangt, het relatietype Klant is, en de rubriek op Archiefrubrieken staat met een andere soort dan geen. De nieuwste eerst.

Een archiefdocument downloaden. Business Central kan de bytes niet via deze codeunit teruggeven zonder afhankelijkheid van de app van iFacto, dus de website haalt ze met de id bij de API van iFacto op:

POST https://api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/api/ifacto/dxsteel/v1.0/companies({company id})/documentArchives({id})/Microsoft.NAV.Download
{}

-> {"value": "<base64>"}

Download alleen een id die voorkomt in de lijst van MyDocuments die u net voor diezelfde sessie hebt opgehaald. Neem nooit een id uit de browser en geef dat ongecontroleerd door: het account van de website heeft leesrecht op het archief nodig om te downloaden, en in hetzelfde archief zitten inkoopfacturen en interne correspondentie. VOA CG S365 ARCHIVE beperkt die toegang met een beveiligingsfilter tot de toegestane rubrieken, maar de eigendomscontrole is MyDocuments. Een lege value betekent dat er geen bestand bij het archiefrecord zit.

Rapportrijen. Alleen documentsoorten waarvoor een rapport is ingesteld (een documentindeling op de klantenkaart, anders de rapportselecties): actuele offertes en orders, geboekte verzendingen, facturen en creditnota's, in die volgorde, elk het hoogste nummer eerst en hooguit 100 per soort.

Document

De pdf van één document, afgedrukt met het rapport dat Business Central daarvoor gebruikt, en alleen bij de bron rapporten: waar het archief van Steel 365 staat, geeft dit altijd "" en gebruikt u de download uit het archief hierboven. documentType is quote, order, shipment, invoice of creditMemo (ongevoelig voor hoofdletters) en documentNo is het nummer. Het geeft "" bij een ongeldige sessie, een onbekend type, een document dat niet bestaat of niet van deze klant is, een documentsoort zonder rapport, of een lege afdruk. Offertes en orders moeten actueel zijn; gearchiveerde versies zijn niet af te drukken. Verder komen fileName, contentType en base64 terug, de pdf zelf.

Het rapport draait met de rechten van het websiteaccount (tenant-set VOA CG DOCUMENTS). Mislukt het rapport, meestal doordat een eigen indeling een tabel leest die de set niet dekt, dan mislukt de aanroep met een fout die het object noemt; zet die tabel in de set. Een download archiveert de offerte of order niet, maar de standaardrapporten verhogen wel Aantal afgedrukt. hasDocument in MyQuotes, MyOrders en MyShipments is precies dan true als de bron rapporten actief is en er voor die documentsoort een rapport voor deze klant is ingesteld.

Vaste waarden

Deze waarden zijn vaste merktekens. Ze worden nooit vertaald en hangen nooit van de taal van de sessie af. Vergelijk ze exact.

Aanvraagnummers komen uit nummerreeksen in de instellingen. Bij de installatie staan die standaard op WEB000001 tot WEB999999 voor offerteaanvragen en ACC000001 tot ACC999999 voor accountaanvragen, maar elk bedrijf kan ze wijzigen: vertrouw niet op het patroon.

Verschillen met Steel 365

CustomerGate 365 is één app. Hij kijkt zelf naar de omgeving en heeft daar geen instelling voor nodig: Steel 365 is actief zodra het veld Quantity Pieces DMX op de verkoopregel bestaat, en het documentarchief van Steel 365 zodra de tabel Document Archive DADMX bestaat.

Het documentarchief is een aparte schakelaar:

Versies en compatibiliteit

De namen zijn het contract. Websites roepen ze letterlijk aan, dus dit hoort er allemaal bij: de namen van de services, de namen van procedures en parameters inclusief hoofdletters, de namen van de cataloguseigenschappen, de JSON-sleutels in payloads en antwoorden, en elke vaste waarde hierboven. Eén ervan hernoemen breekt elke website die op de app is gebouwd, in veel gevallen stilzwijgend: een hernoemde cataloguseigenschap laat gewoon een kolom leeg, en een hernoemde JSON-sleutel leest als null. Er zijn geen aliassen voor eerdere namen.

Voor wie de services gebruikt:

• Negeer sleutels die u niet kent. In een compatibele release kunnen er sleutels bij komen.
• Behandel een ontbrekende optionele sleutel als null, en "" als geen waarde.
• Behandel een onbekende waarde als onbekend. Vertaal haar niet naar een standaard die iets beweert, bijvoorbeeld door een onbekende outcome als recorded te lezen.
• Houd het sessietoken, de requestId en de sleutel voor de IP-hash aan de serverkant.

Een sleutel, een procedure of een cataloguseigenschap toevoegen is een compatibele wijziging; er een weghalen of hernoemen niet. De installatie en updates maken ontbrekende services aan, maar wijzigen nooit een bestaande: een hernoemde service zou naast de oude komen te staan, terwijl de oude blijft wijzen waar hij wees.