verwijder query VBA

Goedemiddag,
Ik ben op zoek naar een code om 2 tabellen te vergelijken.
Ik heb een tabel met artikelen, met prijzen en voorraden. Deze tabel zit in de kassa.
Daarnaast heb ik een tabel die vanaf de website komt met artikelen en prijzen, zonder voorraden.

Ik heb een query die de prijzen van de artikelen van de kassa aanpast naar de prijzen van de website.
Dus als een artikel, waar voorraad aanwezig is ook op de website staat, dan wordt de prijs aangepast op de lijst van de kassa, naar de prijs die het artikel op de website heeft.
Dit is prima.
Nu wil ik graag elke dag de artikelen van de website naar de kassa zetten met bijbehorende prijzen. Alleen moeten de artikelen die al aanwezig zijn blijven zoals ze zijn op de kassa omdat anders de voorraden weggaan.

Ik ben nu op zoek naar een code die de artikelen welke aanwezig zijn op de lijst van de kassa gaat wissen op de lijst van de website en daarna alles samen gaat voegen tot 1 lijst.
Ik krijg dan een lijst met artikelen die op de website voorkomen, zonder voorraad met de artikelen die op de kassa aanwezig zijn met voorraad.

Mijn tabellen zijn tbl_artikelen (van de kassa) en de tabel tbl_prijslijst_website.
Ik zou erg geholpen zijn met een soort verwijderquery die op de prijslijst van de website die artikelen weghaald, die op de prijslijst staan van de kassa.

Ik hoop dat ik een beetje duidelijk ben.

Alvast bedankt.

MVG Frank

Nou, duidelijk... Nee dus. Begin eens met uit te leggen in welke taal je e.e.a. wilt hebben: Fortran, Pascal, Cobol?

Ja sorry, ik dacht dat ik in de rubriek access zat. In access dus.

Dan is het handiger om de vraag naar het Access forum te verplaatsen . Neemt niet weg dat ik de procedure nog niet helemaal snap, want Access kan volgens mij niet rechtstreeks met een website communiceren. Dus leg eens uit wat je precies aan het doen bent.

Hallo Octafish,

Nee, het klopt dat access niet kan communiceren met een website.

Ik krijg dagelijks een xml bestand van de dealer met artikelen, afbeeldingen en omschrijvingen van ongeveer 1200 artikelen.
Dit bestand haal ik binnen in access . Omdat er een historie is, gaat hij kijken of er een historie aanwezig is.
Als dit het geval is laat hij dit in een formulier zien.
De artikelen krijgen per groep(100 stuks) een vaste opslag. Laptops, monitoren etc.
Maar dit is niet voldoende omdat laptops van 400,- een andere opslag moeten hebben als een van 1200.
De prijzen worden gecontroleerd en aangepast op het formulier.
Dit is handwerk en kost veel tijd.
Er wordt dan een historie gemaakt, zodat niet steeds de aanpassingen opnieuw gedaan moeten worden.
Dit werkt perfect.
Dan worden bestanden met alle aanpassingen in een xml-bestand naar de website geupload.

Wat is nu het probleem.
We hebben ook een fysieke winkel met een kassa en daar zitten 3000 artikelen in.
Dus ook de bestanden zoals hierboven vermeld.
Nu moeten de artikelen dezelfde prijs krijgen zoals op de website vermeld.
Nu zou je denken dat het xml-bestand wat naar de website gaat importeren naar de kassa en klaar.
Echter zijn dan de aantallen voor de voorraad ook meteen weg.

Om dit op te lossen exporteer ik het bestand van alle artikelen naar access, daar filter ik op de dealer waar het om gaat.
Ik heb dan ongeveer 200 artikelen met voorraad, maar met de oude prijzen.

Ik kan niet bijwerken, omdat artikelen in de lijst van de dealer ook voorkomen in de lijst artikelen van de kassa, met voorraad. Die is dan weg.
Ik zou dus alle artikelen van de dealer in de kassa willen en als dit artikel al aanwezig was in de kassa, dat deze laten staan met alleen een prijsaanpassing.

Ik heb een code die gaat kijken of er een historieprijs aanwezig is, dit werkt goed en is: IIf(Nz([TBL_Prijslijst_Historie].[Verkoopprijs];0)=0;[tbl_Complies_mutatielijst].[Verkoopprijs];[TBL_Prijslijst_Historie].[Verkoopprijs])
Ik ben op zoek naar iets wat op deze manier werkt met een query. Die in woorden de volgende taak uitvoert:
Importeer alle artikelen van de dealerlijst naar de lijst kassa, maar als dit artikel reeds voorkomt in de kassa, neem dan de bestaande voorraad over en pas alleen de verkoopprijs aan die in de dealerlijst staan.
Tja, mooi gezegd, maar nu de code nog.
Ik hoop dat ik iets duidelijker ben.
Alvast erg bedankt voor je hulp.

Met groeten Frank.

frankie59 zei:

Nu zou je denken dat het xml-bestand wat naar de website gaat importeren naar de kassa en klaar.

Klik om te vergroten...

Lijkt mij ook. Zou moeten werken, als je het correct doet. En dat vraag ik me dus af.

frankie59 zei:

Ik kan niet bijwerken, omdat artikelen in de lijst van de dealer ook voorkomen in de lijst artikelen van de kassa, met voorraad. Die is dan weg.

Klik om te vergroten...

Hoe dat zo? Een bijwerkquery kun je toch doen op basis van een aantal velden? Je hoeft niet alle velden te overschrijven. In dit geval gaat het alleen om de prijzen, dus doe je alleen de prijzen. Eigenlijk snap ik je probleem niet; als het goed is heb je maar één tabel met artikelen, waar ook de Verkoopprijs in staat. Die verkoopprijs wordt blijkbaar regelmatig aangepast, en die gaat dan met een XML export naar de website. Tot zover is het mij duidelijk. Maar die prijsaanpassing heb je dan toch ook al gedaan in de Artikelen tabel? Eerlijk gezegd snap ik de functie van de Historie tabel in deze ook niet, want die zou je helemaal niet nodig hoeven te hebben. Het is mooi om de prijshistorie te bewaren, al zul je er in de praktijk niet veel mee hoeven doen (leuk voor rapportages voor het management), maar de actuele prijs is altijd maar één record in één veld in één tabel. Tenminste: dat lijkt mij logisch .

query vba

Ik begrijp wat je bedoelt. Ik heb een historie nodig om de oude prijzen terug te lezen. 1. ik ontvang het XML-bestand van de dealer. Hier zitten alle bestanden in. Ik heb een lijst gemaakt in Access waarin alle categorieën zitten. Zo krijgen artikelen in de categorie laptops een opslag van bv. 15%. Deze komen in een lijst welke ik met een formulier weer oproep.
In deze tabel staat nu de ruwe opslag voor alle categorieën en alle artikelen hebben nu een nieuwe prijs incl. btw en opslag.
wanneer ik de dag erop een nieuwe export doe, is de ruwe opslag weer in orde. Als ik de categorie laptops de toeslag verhoog naar 25% en de handeling opnieuw uitvoer, dan worden de prijzen gegenereerd met 25% opslag.
1 percentage voor 1 categorie is te grof, dan zijn we te duur of te goedkoop.
Ik heb nu alle artikelen laten opzoeken bij de concurrent en de lijst aangepast, nu heeft elk artikel een concurrerende prijs en is prima af te lezen wat de marge is etc.
Maar als we nu weer het XML-bestand van de dealer gaan importeren, dan is alles weg.
Daar komt de historie om de hoek kijken.
Ik laat voor elk artikel kijken in de historie of dat bewuste artikel aanwezig is.
Is dit het geval dan neemt hij de prijs van de historie.
We krijgen nu een lijst met alle artikelen van de dealer. Alleen de artikelen die we de vorige keer aangepast hebben in ons formulier worden weergegeven met de prijs die wij zelf toegekend hebben en niet de grove prijs.
Door telkens na de mutatie van artikelen een historie te maken, zijn de prijzen actueel en behoeven alleen de nieuwe prijzen die zichtbaar gemaakt worden in het formulier opnieuw bekeken te worden.
Wanneer dit klaar is gaat dit naar de website.

Even als voorbeeld: We hebben in de lijst van de dealer twee laptops staan. Asus 1 inkoopprijs 400,- excl. btw. en Asus 2 inkoopprijs 900,- excl. Beide staan in categorie laptops. In ons Accessprogramma is een lijst aanwezig waarin we opgegeven hebben dat de categorie laptops 18% opslag moet hebben en 21 % BTW.
Deze komen te staan in een zg. mutatielijst. Deze lezen we uit met een formulier, waarin we allerlei aanpassingen kunnen doen. In deze mutatielijst zien we ASUS 1 met een verkoopprijs incl. btw van € 571,12 en ASUS2 met een verkoopprijs van € 1285,02. De winst op ASUS 1 is excl btw. €72,- op ASUS 2 is dit €162,-
De ASUS 2 is hiermee veel te hoog geprijst. en zou rond de 1180,- uit moeten komen. Het kan ook zijn dat de concurrentie op €1.300,- uitkomt, we moeten dit artikel dan bijstellen.
Als dit gedaan is dan wordt de historie gemaakt.
De dag erop wordt het bestand van de dealer weer geïmporteerd, de import wil ASUS 2 een prijs geven van € 1.285,02, maar nu gaat hij, als die aanwezig is de historische prijs invoeren als huidige verkoopprijs.
Hierdoor moeten we 1x alle prijzen actueel houden en daarna alleen de nieuwe artikelen.
Dit werkt goed.

Deze mutatielijst, waar de aangepaste prijzen per artikel aanwezig zijn kunnen we importeren in de kassa, dat zal wel lukken, alles staat er dan in.
De winkelvoorraad is dan weg, omdat van elk artikel het aantal aanwezige aantallen vermeld zijn.
Dat is niet de bedoeling.
Ik kan een lijst maken van artikelen uit de kassa met voorraad, dat is geen probleem.
Maar hoe krijg ik dan de artikelen uit de mutatielijst met de nieuwe prijzen in 1 lijst, waarbij de aantallen(voorraad) overgenomen wordt en er geen dubbelen artikelnummers ontstaan.
Daarnaast zijn er artikelen die niet meer in de dealerlijst voorkomen omdat ze niet meer verkocht worden, maar waar we nog wel voorraad van hebben. Deze moeten ook in de kassa blijven.
Tja, ik wil nogal wat........

Het is te doen om een lijst te maken uit de kassa waar alleen die artikelen opstaan, waarvan er voorraad is.
Deze lijst moet langs de aangepaste mutatielijst van de dealer gelegd worden.
Hieruit moet een lijst komen die de artikelen uit de kassa laat zien met voorraad en waarbij de verkoopprijs aangepast is als dit artikel in de mutatielijst van de dealer aanwezig is.
De artikelnummers zijn uniek.

Het is lastig dat ik je geen voorbeeld kan sturen omdat het allemaal veel te groot is. en werkt samen met onze server.
Dit zou jou veel meer zeggen, denk ik dan al mijn woorden.

Ik hoop dat ik wat duidelijkheid heb geschept, anders hoor ik het graag

Groeten Frank.

Access kan volgens mij niet rechtstreeks met een website communiceren.

Klik om te vergroten...

Het is geen probleem om MS Access (ODBC driver) in PHP (PDO connectie) uit te lezen mits de veldtypen in Access overeen komen met die in MySql, op deze pagina vindt je de veldtypes naast elkaar.

Hallo,
Bedankt voor uw reactie.
Echter is dat niet noodzakelijk, mede ook omdat er op de website niet de werkelijke voorraad zichtbaar is, maar de voorraad van de dealer.
Daardoor is het niet te gebruiken.

Met groeten, Frank

frankie59 zei:

Maar als we nu weer het XML-bestand van de dealer gaan importeren, dan is alles weg.

Klik om te vergroten...

Ik snap er echt helemaal niets van. Sowieso het 'systeem' van één categorie met één opslag die dan veel te grof is, lijkt mij al voldoende reden om de structuur eens tegen het licht te houden. Je hebt ongetwijfeld criteria op basis waarvan je de prijzen verhoogt/verlaagt. Die criteria zouden vast moeten liggen in een tabel en objectief toegepast moeten kunnen worden. Dat kan dus bijvoorbeeld door opslag/kortingen op basis van basisprijs te baseren, en/of op aantallen en wellicht inkoopkorting etc. Kortom: de criteria kun je van tevoren redelijk vastleggen. Vervolgens hoef je in je bijwerkquery alleen maar die criteria op de juiste manier in te lezen om de juiste opslagfactor te zien.
Of je elke dag een export krijgt of niet, maakt voor het systeem volgens mij ook niet uit. En dat 'alles weg' is, komt omdat je importprocedure dan niet klopt. Het mag geen enkel probleem zijn om een XML bestand in een tabel te zetten, zonder dat je oorspronkelijke data vernaggeld wordt. Nogmaals: een Historietabel is niet bedoeld voor je actuele data. Het is Historie, dus oude data. En je haalt alleen gegevens terug uit je historie, als je actuele data naar de sodemieter is geholpen. Wat dus nooit zou moeten!

Ik denk echt dat jullie veel te ingewikkeld werken, en dat er een hoop simpeler kan. Sowieso het feit dat de winkelvoorraad aangepast wordt als je een dealerlijst inleest, is van de zotte. Zelf denk ik dus dat je het mutatieformulier nog wel kan gebruiken (je leest de prijzen in, met wat knopjes waarmee je een oude prijs kan terugzetten bijvoorbeeld als dat nodig is) maar hou om te beginnen de tabellen goed gescheiden, zodat je XML import niet je voorraad leegtrekt. Nergens voor nodig .

query VBA

Ja, Octafish.

Het is ook erg moeilijk uit te leggen en ik denk dat het in het begin te ingewikkeld is opgezet.
Ik zou dan alles opnieuw moeten bouwen.
Het website gedeelte werkt zo ontzettend mooi en zo flexibel, waar eerst 3 uur per dag aan besteed moest worden is nu in 15 minuten klaar.
alleen die verrekte kassa.........

Ik ga eens kijken wat ik met bijwerkquery en verwijderquerys kan bereiken.

Toch bedankt voor je info.

Met groeten Frank

RE: Ik snap er echt helemaal niets van ....
RE: Het is ook erg moeilijk uit te leggen ....

Klik om te vergroten...

Voorbeeld bestanden met fake artikelen zou misschien helpen

Zou inderdaad mooi zijn. Een kopie maken van de tabellen (alleen structuur) die je nodig hebt om het proces te duiden, een paar artikelen er in, een XMelletje erbij met wat dummy data en volgens mij kom je dan een heel eind.