Heart-Profit ERP

Bij het printen van een prijsreglement van 1 debiteur (3-4-7-6-2) en het daaraangekoppelde genereren van een excel sheet (direct vanuit de functie, niet vanaf schermprint conversie) komen de prijzen niet in de gewenste valuta, maar in de databasevaluta (in ons geval nog steeds NLG)


:17c:

Da's voor de nostalgischen onder ons.
Wij dachten dat jij daar bij hoorde.  :dntknw:

Svp even een konkreet voorbeeld geven. Welke Debiteur? Hoe vul je de schermen van Tabblad 1 en 2 in?
Daarnaast impliceer je dat het bij de niet-excell versie goed gaat. Klopt dat of heeft de melding niets met de export naar Excell te maken?

Tja ... aan de ene kant moet ik Wouter er gelijk in geven of (bijvoorbeeld) de "1 debiteur" zoals genoemd nu inhoudt dat het bij meerdere wel goed gaat, en je dùs aan de rest ook maar gaat twijfelen (ik vroeg het me in elk geval ook af). Maar :

Aan de andere kant kun je het ook niet helemaal maken om te suggereren dat het misschien niets met de export naar Excel heeft te maken ...

Feit blijft dat het onnodig onduidelijk is gesteld, wat inhoudt dat wij onnodig moeten gaan zoeken.

dacht dat ik duidelijk was, maar hier is screendump, maar dan het vinkje aan bij "opbouwen in excel"

 :( ?????

Ok. Tab #1 heb ik nu, nu Tab #2 nog, en antwoord op de vraag:

Hij blijft maar doorzeuren heh.  :yes:

OffTopic :

MK, als je deze even doorneemt, kun je je schermprintjes wat makkelijker maken, denk ik : http://ha1.heartprofit.nl/profit/index.php?topic=17257.0

tab 2

MK,

Eerst wil ik er met klem op wijzen dat ik hier de moderator uithang, en niet jouw superieur. Dus onder het motto "even goede vrienden" *en* respekt uiteraard, toch het volgende :

Gisteren heb *ik* jouw signature dan maar gemaakt, en heb *ik* jouw mislukte avatar maar weggegooid. Waarom je dat niet doet waar het eerst regel is, vervolgens wordt gevraagd, later nogmaals wordt gevraagd ... ik weet het niet. Ik hoop in elk geval dat je (en iedereen) inziet dat wij dit voor iedereen op deze manier doen, en dat het veel profijt gaat geven.

Zou je nu de vraag van Wouter willen beantwoorden ?
Ik heb mijn best gedaan om de vraag van hem niet opportuun te vinden, maar kennelijk wil Wouter het toch weten.

Ik hoop ook dat iedereen begrijpt dat waar een klant binnen 5 seconden een antwoord kan geven, wij in het luchtledige kunnen zoeken als we niet goed weten wáár we moeten zoeken. Dat een klant (of ik  ;) ) niet begrijpt waarom de vraag wordt gesteld moeten we dan maar afstand van nemen.

Dank je !

Voor de goede orde: het printje naar scherm of papier gaat goed, maar het opbouwen in excel geeft database valuta (guldens) en die zoeken wij niet. Lijkt erop dat een conversie die wel wordt gemaakt bij de print niet in de subroutine voor excel is ingebouwd.

Lijkt me dat presentatie in bedrijfsvaluta gaat als het vinke debiteur valuta uit staat en in debiteur valuta als deze aan staat. Nu krijg ik echter in excel de database valuta en dat is niet wat we zoeken.

:17c:

Hmm... Dát had ik om te beginnen niet verwacht, immers hetgeen in Excel gebeurt is een aanvulling op hetgeen naar papier ging. De data wordt eerst opgebouwd in een tijdelijk bestand, en daarna gaat dit òf naar de printer òf naar Excel. Omrekeningen vinden in dat trajekt wat mij betreft niet plaats.

En dus toch maar eens even snel op jouw systeem gekeken. Nadat perikelen van met password geblokkeerde modem-pc's zijn verholpen, mag ik dan eindelijk de prints opstarten met de gegeven informatie, en met als resultaat:

Nou... zoek zelf de verschillen maar... Ik heb NAW, Artikelen etc. buiten de scherm kopie gelaten, maar je herkent de overeenkomsten wel. De een is een print naar het scherm, de ander naar Excel.

Nb: Hiermee is overigens niet gezegd dat je geen probleem hebt, maar schijnbaar moet je meer doen om dit voor elkaar te krijgen. Excel ingesteld om alles in guldens te tonen? Presentatie-Valuta op guldens gezet? Hoe dan ook... kom met het voorbeeld waaruit blijkt dát het niet klopt, dan hebben we iets waar we naartoe kunnen werken (in plaats van ons een breuk te zoeken).

Ik zie dat ik bij de excel versie niet over heel 2007 berekend heb, maar daar zal het niet aan liggen. Toch?

Papier of Excel maakte inderdaad niets uit. Buiten het forum om heeft mdekraa alsnog aanvullende informatie toegezonden, en uiteindelijk hebben we de oorzaak gevonden.

Waar bij een Prijslijst-id een Valutakode kan worden opgegeven, wordt deze Valutakode wél gerespekteerd door 3-4-1-1 maar niet door 3-4-3.

Zo zijn we in staat om via 3-4-1-1 een prijs vast te kunnen leggen van USD 2000,- per TN.
Vragen we die prijs op via 3-4-3 dan wordt ineens 907,- getoond (euros).

De 2000,00 wordt door 3-4-3 gelezen als 'tarief in de databasevaluta' die in dit voorbeeld op NLG staat. Het bedrag wordt vervolgens gepresenteerd in de presentatievaluta EUR.

Andersom, als nu de Staffelprijzen zijn ingevoerd via 3-4-3 dan zullen deze tarieven in de database-valuta worden opgenomen in de database, dit terwijl ze horen te worden opgenomen in de valutakode van de Prijslijst-id. Het invullen van een prijs van EUR 1,- komt dus in de database terecht als NLG 2,20371. Het prijsreglement, die wel netjes de Valutakode van de Prijslijst respekteert, ziet deze 2,20371 dus als euro bedrag.

Ofwel, de tarieven zoals in de eerder genoemde printscreen getoond zijn de tegenwaarde in guldens van prijzen die in euro ingevoerd zijn.  :crazy:

Wat nu even minder handig is, dat het er schijnbaar vanaf hangt hoe de gebruiker zijn prijzen vastgelegd heeft. We kunnen dus niet per definitie stellen 'alles staffels respekteren de valutakode van de prijslijst-id niet' immers alleen de via 3-4-3 ingevoerde staffels doen dat niet. Tijdens de eerst volgende upgrade zal er dan ook gekontroleerd worden òf U met Prijsstaffels voor Prijslijst-id's werkt. Mogelijk wordt er dan een waarschuwing gegeven kontakt op te nemen met Heart opdat in overleg kan worden bepaald hoe de prijzen gekonverteerd moeten worden. :(

Merk op dat indien U enkel met Prijslijst-id's in EUR werkt, en Uw database-valuta eveneens EUR is, dit probleem niet kan optreden.  ;)

Tijdens "een" volgende upgrade;
ik kan natuurlijk niet garanderen dat dit probleem meteen vandaag nog is opgelost.

Hetgeen geruststellend is voor Nieuwe Heart gebruikers, maar wat nu met ons, die mensen die nog vast zittenaan databases met euri?
Op termijn toch NLG vervangen middels conversierun of blijven we ieder jaar NLG bugs vinden?
 :'( SNIEF

Wij hebben in de database nog lire staan.

is echt lachen als die worden gelezen als euro's

:holiday: :holiday: :holiday:

Dirk-Jan Gloudemans
LA

Dit heeft niets met NLG bugs te maken. Immers, als je database-valuta EUR was geweest, zou een prijslijst in USD in EUR in de database komen.
Is nog steeds verkeerd, want de prijslijst is in USD en moet in USD in de database komen. :P

Konversierun? Als je (we) überhaupt al per record weten te bepalen in welke valuta ieder numeriek veld staat (er zijn 1500 bestanden, met in totaal misschien wel 10.000 numerieke velden) dan zal zo'n konversie wel eens een week kunnen draaien; leg jij een week je bedrijf plat voor een konversie?  ;)

De keuze destijds wel/niet te konverteren is bewust gemaakt.

Overigens hebben we wel bij een enkeling alsnog een bedrijf helemaal opnieuw opgezet, maar dan in EUR. Hierbij geen 1:1 konversie, maar hooguit 'stambestanden importeren uit een ander Profit bedrijf' en opnieuw beginnen. E.e.a. op nacalc. basis, per situatie te beoordelen, en geen historie meer in het nieuwe bedrijf (dus geen vergelijkingen met vorige periodes). Wordt dus meestal gekombineerd als iemand toch wil overstappen op een totaal andere wijze van inrichting van het pakket, waarbij de euro dan meteen wordt meegenomen. Normaliter is dit geen optie, immers, wie wil zijn historie nu kwijt raken?