Upgradeberichten‎ > ‎

UPDATE 012 (29/04/2016)

Geplaatst 29 apr. 2016 06:13 door Parcours vzw   [ 29 apr. 2016 07:05 bijgewerkt ]


  • planning board (lokalen plannen/materialen plannen) fixes de afgelopen weken: 
      1. Je kan nu losse reservaties toevoegen via het planning board, voor materialen en lokalen. Ga gewoon op een tijdvak en datum staan en dubbelklik. Normaal gezien is dat meteen een definitieve reservatie. Vergeet niet op te slaan.
      2. Bij dubbele (overlappende) boeking in hetzelfde lokaal of hetzelfde materiaal op hetzelfde moment verschijnt nu een icoontje (een uitroepteken)
      3. Als de persoon of de organisatie ingevuld is op reservatie, dan verschijnt er ook een icoontje, een huisje. Dat is dus om aan te duiden dat die reservatie voor extern gebruik is (meestal verhuur).
      4. Bug dat sommige activiteiten niet altijd zichtbaar waren in planning board: opgelost.
      5. Je kan nu dus aan de slag met het plannen van lokalen en materialen zonder bugs tegen te komen (hout vasthouden). Alexandra Meijer bereidt een opleiding voor over planning board en reservaties.
      • Personen: actief of niet? Op 'personen' is er een aanvinkvakje 'actief'. Je kan dit gebruiken op verschillende manieren. Het enige wat dit doet is een waarschuwing geven als je deze persoon wilt inschrijven. Het kan gaan om een overleden persoon of om een wanbetaler of ... Dat veld stond er al maar de waarschuwing is nu geïmplementeerd, dat was ervoor nog niet.

      • De tekstblok van de overeenkomsten, die je bij overeenkomsttypes invult, werd niet gesplitst over verschillende pagina's op de PDF, met veel witruimte tot gevolg. Opgelost.

      • Bug wachtlijstmail: De mail naar de mensen die via website ingeschreven hadden, werkte niet. Opgelost. Dus vanaf nu vertrekken ze wel, opgepast dat je vanaf nu geen dubbele mails stuurt (de automatische + manuele).

      • Betalen met Cultuurcheques: Je kan die velden van cultuurbonnen nu ook officieel in gebruik nemen en zeker zijn dat het ook goed komt in Exact. In de setup (vraagt het aan je SuperUser) kan je nu niet alleen voor de cultuurbonnen een standaard grootboekrekening opgeven (dat was al) maar ook voor cultuurcheques. Dus dat eerst instellen wel. Zie ook Carine haar uitleg in het document: https://docs.google.com/document/d/1_JyeVYeF_LLuEVsSyqeiXSGpaGHH9w9meEYGVkNl6ts/edit?usp=sharing
        Op het overleg met de collega's van inschrijvingen kwam de vraag: wat als klanten teveel betalen met cultuurcheques omdat we niet mogen teruggeven? Dan moet je dus een correctietarief aanmaken op de activiteit. Via de link 'Nieuw Tarief Activiteit' bij de bewerkpagina van een deelnemer. Anders komt het wel goed in Exact maar niet in SF: totaal te betalen bedrag zal negatief zijn, alsof die persoon nog moet terugkrijgen. 

      • 'Creëer verkoopfactuur' = een knop op inschrijving bovenaan. Die heet nu 'kopie verkoopfactuur', dat is correcter. het is gewoon een PDF van een boeking die al in Exact zit, daarmee creëer je geen nieuwe factuur, maar krijg je een kopietje dat je kan verzenden en waar je nog wat aan kan toevoegen qua uitleg.

      • Voor de centra die met logins voor externen werken (maar ook handig misschien voor bepaalde andere gebruikers): er zijn nu bij gebruikersbeheer (in setup) bij elke gebruiker drie checkboxes, tenminste: als je die op de layout van de pagina van de user sleept (in moederorg zette ik ze onder de sectie 'aanvullende informatie')
        • 'betaald bij partner' aan =  Als je aanvinkt, dan zal bij elke nieuwe inschrijving die deze gebruiker aanmaakt 'betaald bij partner' automatisch aangevinkt staan.
        • 'geen betalingsverzoek mailen' aan = Als je aanvinkt, dan zal bij elke nieuwe inschrijving die deze gebruiker aanmaakt 'geen betalingsverzoek mailen' standaard aangevinkt staan
        • status definitief inschrijving blokkeren = Als je aanvinkt, dan zal deze gebruiker een inschrijving nooit de status 'definitief' kunnen geven.
        • Voor wie de oude checkbox 'partner user' aangevinkt had bij sommige users: dit zal na deze upgrade dus verdwenen zijn. Gelieve de checkboxes die van toepassing zijn nu bij al die gebruikers aan te vinken.

      • Validaties op publication start en publication end van een activiteit: vroeger kreeg je al foutmeldingen bij aanmaak van een activiteit als bv de datum van publicatie-einde voor die van publicatiestart viel. Dat zorgde voor heel wat frustratie bij bv klonen van activiteiten of bij aanmaak van activiteiten die al voorbij waren. Nu worden die foutmeldingen pas gegooid op het moment dat de activiteit definitief wordt gezet.

      • Op datumvelden zoeken gaat standaard niet in Salesforce. Maar er is wel een workaround: we kunnen in de moederorg velden kopiëren die dan wel gevonden worden door de zoekmachine van Salesforce. Geboortedatum hadden we zo al bij migratie vindbaar gemaakt, nu is ook 'start eerste sessie' te vinden via de zoekfunctie. Zowel in vorm '24/04/2016' als '24042016'. Handig toch?

      • Op alle orgs heb ik de rapporten voor de betalingsherinneringen aangepast. Vanaf nu zullen die inschrijvingen waarbij er enkel een bedrag ter plaatse betaald moest worden geen betalingsherinnering meer krijgen. Beste Superuser, kijk ook je mailtemplates na: welk mergefield gebruik je bij een betalingsherinnering voor het bedrag dat in de mail vermeld staat dat betaald moet worden? Je kan kiezen uit het bedrag dat vooraf betaald moet worden ('total amount to pay in advance') of het totaal te betalen bedrag ('Total amount to pay'), ongeacht of er iets ook ter plaatse betaald kan worden.

      • De inschrijvingsdatum van de deelnemer wordt aangepast wanneer een deelnemer naar status definitief gaat (van bv wachtlijst, bij toevoeging van een nieuwe deelnemer aan een definitieve inschrijving of wanneer een geannuleerde terug definitief wordt). De rapporten van de betalingsherinneringen heb ik bij jullie allen zo aangepast dat die zich ook baseren op die inschrijvingsdatum op niveau van de deelnemer, zodat bij meervoudige inschrijving het risico er niet in zit dat er al een rappel volgt terwijl er net een deelnemer is veranderd naar definitief. Ik heb twee velden nu ook anders vertaald: 'Inschrijvingsdatum inschrijving' en 'Inschrijvingsdatum deelnemer' omdat die twee dus verschillend kunnen zijn (voorheen alletwee gewoon 'inschrijvingsdatum'). Inschrijvingsdatum van de inschrijving wordt enkel en alleen aangepast wanneer er nog geen sync was met Exact (anders is er een probleem met de volgorde van de boekingen in Exact. Dus in het geval van wachtlijst of een geannuleerde die nooit definitief gezet werd.

      • Pakketactiviteiten: er zat nog een bug op dat een lead niet kon inschrijven voor een pakket. Opgelost. Daarnaast is toegevoegd dat als je een definitieve activiteit toevoegt aan een pakket waar al inschrijvingen voor zijn, dat die deelnemers automatisch ook ingeschreven zijn voor die nieuwe activiteit. (dat is wenselijk, maar wel opletten dus dat je niet per ongeluk een activiteit toevoegt aan een pakket! Dat is niet echt omkeerbaar omdat er inschrijvingen zijn dan). En een aantal validaties want die pakket kon je wel verknoeien als je daar zin in had. Nu dus niet meer ;)

      • Een aantal centra was nog bezig met het aanpassen van de grootboekrekening die gekoppeld is aan de activiteiten van 2016. Nu blijkt dat die sync met Exact andere neveneffecten heeft die niet gewenst zijn. We moeten dat dus voorlopig blokkeren. Vanaf nu kan je de grootboekrekening van een activiteit niet meer aanpassen nadat ie definitief gezet is. Jullie superusers kunnen er wel in die zin flexibel mee omgaan dat je de validatie kan uitzetten zolang er nog geen inschrijvingen hangen aan die activiteit. Tot dan kan het geen kwaad om die nog aan te passen. Maar het beste is dus om er zeker van te zijn bij definitief zetten dat de grootboekrekening klopt. Graag een beetje samenwerken met je boekhouder daarvoor.

      • Er zijn nog heel wat Exact-sync bugs uitgehaald. Er zat een probleem bij de credit nota's wanneer een inschrijving al deels betaald was. 
        Opgelet: SF houdt nu dus rekening met betalingen om het bedrag van de creditnota te bepalen bij annulatie. Da betekent wel dat het goed afgepunt moet zijn in Exact, de betaling, anders kan SF niet weten hoeveel er al betaald is op die boeking.  

      • Wat wel nog het geval is, is het volgende: als je een definitieve deelnemer toevoegt aan een betaalde inschrijving die op 0 is gekomen door annulatie(s), dan vervalt de credit nota niet. Dus als het tarief van die nieuwe deelnemer hoger is dan het reeds betaalde bedrag, dan lijkt het alsof de credit nota moet uitbetaald worden én dat de klant moet bijbetalen. Tegen elkaar af te punten in Exact als je niet wilt dat die twee acties moeten gebeuren. Later meer hierover in de Exact collegagroepen. We gaan ook een test opzetten bij enkele centra om de procedures rond terugbetalingen te stroomlijnen via rapporten en list views.

      • De grootste bug die er nog in zat was wellicht die dat de creditnota's van aankoopfacturen geen negatief bedrag opleverden in Exact. Gelukkig had nog maar één centrum (archeduc) een creditnota bij de aankoopfacturen. Wouter, bekijk je eens met Karin wat we ermee doen? Want het gaat over een creditnota van 2015, dus ik durf die dan niet zomaar opnieuw syncen bij een afgesloten boekjaar.

      • Alle vertalingen zijn nu gebeurd (muv Babbler die ik niet zelf kan/mag vertalen). Er zijn ook velden beschikbaar gemaakt voor aangepaste rapporttypes die eerder niet konden gebruikt worden in bepaalde rapporten.
            Comments