Access - Llamar a una Consulta de anexion con VB

Soy bastante novato en Access, y he creado una Consulta de Anexion para unir dos tablas y tengo la necesidad de llamar a esa consulta desde un Procedimiento de Evento, ya que previamente a esta llamada de la consulta hago varios procesos previos y despues tengo que llamar a la Consulta de anexion y no se como dar la instrucccion de llamarr para que se ejecute dicha consulta.
Os agradeceria muchisimo si pudieseis darme los pasos que tengo que seguir. Muchas gracias de antemano

Hola!

En el evento que necesitas le generas código y escribes:

docmd.setwarnings false
docmd.openquery "NombreConsultaAnexion"
docmd setwarnings true

Si quieres que te lance avisos quítale los docmd.setwarning, pero si los pones asegúrate que tras desactivarlos (false) los vuelves a activar inmediatamente (true), puesto que te los quita no sólo para la ejecución de la consulta, sino para todos los avisos de la aplicación.

Un saludo,

http://neckkito.siliconproject.com.ar/

La alternativa (supongo que mas sencilla para un poco experto), es crear una MACRO y adjudicársela al evento, hace 'lo mismo' que con VBA, pero asistido por Access, lo que evita meterse en un mundo que al momento actual, parece desconocido o poco dominado.

Indudablemente, y para este caso en concreto, lo más sencillo es el uso de macros, como bien se comenta. Sin embargo, cuando tus metas te llevan a niveles de complejidad más profundos, soy de la opinión que es mejor dirigir el esfuerzo de aprendizaje hacia código VBA en lugar de centrarse en las macros.

Lo anterior matizando que siempre (y quizá no debería ser así) doy por supuesto que hablamos de aplicaciones Access de escritorio. Si la intención es crear una aplicación web tendría que decir "donde dije digo digo Diego", dado que, por el momento, estas últimas sólo aceptan macros, como es bien sabido.

Sin lugar a dudas entiéndase lo anterior como mi opinión estrictamente personal.

Saludos,

Neckkito

Indudablemente el manejo de VBA da todo el poder sobre la aplicación y en un futuro mas o menos próximo también se podrá utilizar en la nube (solo precisan una mayor capacidad de análisis para evitar intentar lo que en ese instante sea imposible)

Pero se debería considerar que las macros son un/el peldaño intermedio entre el mundo con VBA y sin VBA, por ello y desde siempre se pueden 'convertir' las macros en funciones, son útiles par aprender como lo hace (y necesita Access) y después se podrá reutilizar sin mermas lo que ya esta hecho (macros ==> VBA).

Enrique:

Si se me permite la expresión, "pluguiera a Dios que Microsoft te escuche". Yo sería el primero en celebrar tamaño acontecimiento.

Sin embargo, permíteme ser un poco más pesimista y ese futuro que comentas lo veo aún muy lejano, básicamente por dos motivos:

- El primero, porque Microsoft le dio un empuje a las macros sacándose de la chistera las macros de datos. De eso deduzco que los responsables de Access centraron sus esfuerzos en potenciar el uso de macros y no VBA (esas macros de datos se convierten en procedimientos almacenados en una aplicación web... supongo que tenían esta característica en mente al planteárselas... supongo).

- El segundo, porque por todo lo que he podido oír y leer las novedades de Access 2016 en relación a Access 2013 tienden, sorprendentemente, a cero.

La verdad es que el esfuerzo invertido, por ejemplo, en Excel 2016, además de sacar herramientas "accesorias" (por llamarlo de alguna manera), como PowerBi, no se corresponde en absoluto con el esfuerzo invertido en Access. Es más, PowerBi admite orígenes de datos de Excel, de SqlServer y de un buen número de otras fuentes... menos de Access. ¿Cómo es eso posible? Sinceramente no lo entiendo.

Insisto: ojalá Microsoft dedique sus recursos a permitir el uso de VBA para aplicaciones Access Web. Creo que de producirse daría una fiesta e invitaría a todos los miembros del foro

Un abrazo,

Neckkito

Yo que soy un usuario que tiende a lo optimista creo que seré uno de los que acudan a esa fiesta (si no es en cuerpo, al menos lo será en espíritu) (solo depende de 'cuando se produzca el cuando')

Muchas gracias por todos tus consejos.
Optare por hacerlo a traves del Evento ya que estoy usando el evento al hacer click y necesito colocarlo a continuacion de otra funcion en ese punto y no puedo llamar a una Macro.
Muchas gracias por tus consejos. Un saludo

Hola de nuevo, he realizado los pasos que me indicaste a traves del Evento y me funciona.
Pero no se como indicarle a la Consulta de Anexion que solo me busque las lineas de venta del Cliente que estoy tratando.
La unica manera que lo consigo realizar es dandole de forma Manual a traves un campo que he puesto en Criterios y que le doy el numero de Cliente cada vez que ha de ejecutar la consulta.
Ademas he notado que revisa todas las lineas pendientes de Facturacion para comprobar si son del Cliente que le he dado de forma manual y el proceso se hace un poco lento.
Como podria darle el Criterio que busque el Cliente que esta en ese momento en Pantalla.?
Gracias de antemano por atenderme de nuevo.
Un saludo

Suponiendo que te manejas con identificadores, y que en la pantalla (esto es, en el formulario) tienes el identificador del cliente en un campo llamado [Id], en tu consulta, si no lo tienes ya, añades el campo [Id] (tu ya verás si es necesario marcar o no el check de mostrar) y, como criterio, le escribes:

Forms!NombreFormulario.Id.Value

Saludos,

Neckkito

He colocado tus instrucciones en el evento y no me pide realmente ya el numero de identificador del Cliente y me pasa perfectamente las lIneas a la Factura.
Pero a la vez me añade miles de lineas mas con numeraciones altisimas son como 100.000 lineas de productos diferentes con una numeracion altisima si esta por la linea 255 las lineas de la factura, estas lineas empiezan a numerarse por el numero 250.000 o mas alto. A que puede deberse esto?

A pesar Necko y Enrique que estoy en Costa Rica muy distante de uds yo también celebraría
semejante acontecimiento.

Saludos ....

Convierte tu consulta de anexión en una consulta de selección y, con el formulario abierto, ejecútala, a ver qué registros te devuelve

Quizá necesitas que alguno del resto de campos que utilizas también tenga un filtro.

Si no, sin ver qué estás haciendo, no se me ocurre qué puede estar pasando.

Saludos,

Neckkito

Buenas José

para llamar en criterio ese campo utilizando el set warning que te indica necko

debes de a esa consulta modificarla en modo diseño y en criterios darle a la botonera de arriba a un botón parecido a una barita mágica y que te ayudara enlazarla con el campo de tu formulario que contiene el id que hara el filtro.

Un saludo....

Hola de nuevo.
Te explico lo que hace la Consulta de Anexion.
Por cada nueva transaccion que hago de pasar de Ventas Caja a Factura,
Ejemplo:
-> La nueva venta tiene 2 lineas
-> En Facturacion Existen 5 Facturas ya creadas anteriormente
Al ejecutar la consulta de Anexion crea esas dos lineas de venta por cada una de las facturas ya existentes, o sea que crea 10 nuevas lineas.
En el caso de existir 50 Facturas crearia 100 lineas. Crea lineas por cada una de las facturas que puedan existir, por eso me creaba tantas lineas por cada vebta como te dije, por la existencia de facturas ya creadas antyeriormente.
He borrado los Historicos y me he dado cuenta de lo que hace el proceso de anexion.
He puesto los criterios como me dijiste pero se ve que no los controla bien y me crea tantas lineas.
Que crees que pueda ocasionar esto?.
Muchas gracis y un saludo.

Crei que el problema estaba solucionado, pero veo que no logras el éxito que necesitas.

Bien, quieres VBA, pero si lo deseas hacer bien, mezclar VBA, con consultas guardadas y con la toma de datos del formulario actual en una combinación poco eficiente (y a la muestra me remito).

Todas las consultas guardadas (y en general las que se crean con el generador grafico) no son mas simples SQLs (su esqueleto interno) que se puede ver e incluso copiar si se pone en lo que Access denomina 'Vista SQL (una de las opciones del menú, en la misma ubicación que 'Vista Diseño')

Pon esa consulta en su 'vista diseño', copia el texto y publícalo (no creo que sea un problema, no mostrara ningún dato ni sensible ni insensible).

Viendo esa consulta se tendrá una idea mas clara de cual puede ser la causa, por cierto si te es posible indica 'que dato' de los que aparecen en ella es el que te solicita (y como se llama realmente en el formulario).

Solo un par de detalles mas que añadir:
.- Se intentara ejecutar esa consulta en y desde VBA como tal consulta (incluso podrías borrar la actual consulta guardada), pues puestos a hacer bien las cosas ...
.- Como simple anécdota: una macro puede hacer 'tantas cosas' como se puedan hacer en un procedimiento o sub (no 'olvides' que las macros se convierten con un simple click en 'código VBA' y funcionan igualmente ...)

Hola, como estas?, este es el resultado de lo que estoy probando

Si la nueva venta que voy a convertir en factura tiene 3 lineas, o que hace el evento es que me crea tres lineas nuevas por cada una de las lineas ya ecistentes con anterioridad en la Facturacion.

Luego me cambia el identificador de la relacion con la cabecera de las filas ya insertadas anteriormente.
No se ya como controlar esto. Si quieres te podria mandar una mini BD del proceso que estoy tratando para ver si tu puedes ver algo y comprobar los procesos. Pero para esto me tendrias que decir como he de reducirla y mandarte solo los procesos que intervienen en esta facturacion.
Un saludo

Vamos a centrar el problema (tal como me ha parecido que se produce).

En un supuesto previo a la modificación de hacerlo con VBA, se supone que la consulta de inserción solicitaba un dato y hacia lo que tenia que hacer sin cosas extrañas.

En la llamada mediante VBA como línea añadida en el evento que al parecer ya existía en la que me extraño un poco lo de:
... ya que estoy usando el evento al hacer click y necesito colocarlo a continuacion de otra funcion en ese punto y no puedo llamar a una Macro.

Algo con lo que estoy en total desacuerdo, con VBA se puede 'llamar a una macro' al igual que se llama a una consulta o 'cualquier otra cosa', en eso resiste el poder (y la perdición) del VBA: el que se interactúa a un nivel mas bajo (por ello hay que ser mas conciso al programar).

Pero eso es otra historia, lo concreto es que la llamada 'parecía funcionar bien' pero se quería algo mas, que NO solicitase el parámetro, al modificar ese punto (modificación no publicada) es cuando se detecta el problema.

Esa es la causa que me lleva a solicitar la consulta que 'antes funcionaba correctamente' así como el dato que se le daba, para analizar la interferencia (que también es probable que la causa sea el evento y el código), pues por ejemplo si en el hay un bucle y dentro se añade la inserción, podemos tener 'el lio montado'.

Si lo anterior parte de una equivocación (antes también incorrectamente pero no se detecto) es el momento de aclararlo y no liar mas la madeja, habrá que localizar el punto en que el diseño no es correcto para solucionarlo.

Al respecto de compartir la aplicación (sea en parte o totalmente) es un punto en el que no entro ni salgo, lo adecuado en el caso de publicarlo seria que la publicaras aquí (habrá mas de dos y de cuatro ojos para analizarla) y además es lo correcto, lo de reducirla .... hay dos formas en lo que supongo que será una copia, se le van eliminado lo que se tiene la seguridad de que no es necesario y el resto ... se puede quitar y en caso de error se importa/copia de la aplicación 'madre', tras ello se comprime en ZIP (solo porque ese compresor viene integrado en el sistema operativo lo que lo convierte en universal) y ....

Voy a comprimirte el Programa en el apartado de ventas por caja y asi tu mismo puedes comprobar el resultado de todo lo que estamos tratando.
Cuando puedas mandame tu direccion de correo y yo este fin de semana te reduzco la copia del proceso del que estamos hablando y te la mando, si te parece bien.
Un saludo

Si ya que veo que varios maestros de la programación no te pudieron ayudar

Lo mejor es como dice Enrique que compartas una parte clonada del problema así necko o enrique podrán analizarla mejor.
Porque yo en lo personal no se que estará pasando.

En alguna parte de mi anterior mensaje deje esto por escrito:

Al respecto de compartir la aplicación (sea en parte o totalmente) es un punto en el que no entro ni salgo, lo adecuado en el caso de publicarlo seria que la publicaras aquí (habrá mas de dos y de cuatro ojos para analizarla) y además es lo correcto

Hola de nuevo.
La verdad es que no se como he de hacerlo para publicarlo aqui. He preparado una MiniBD de la parte que estoy intentado hacerla funcionar y si me comentas como hacerlo lo haria.
Dame los pasos que he de hacer para poderla compartir y asi podais verla.
Un saludo. y gracias

No se si en tu editor de mensajes (cuando inicias una respuesta) en la parte inferior sale un acceso (botón o como le llames) con el titulo 'seleccionar archivos' , es la forma de publicarlo sin intermediarios.

La alternativa (que también hay en otros muchos foros por temas de seguridad) consiste en subir la base a cualquiera de las paginas gratuitas o privadas que hay y publicar aquí el enlace (generalmente esas mismas ubicaciones generan un enlace en forma de accesos directo para copiar y pegar)
También esta la alternativa de los alojamientos en la nube (DropBox y asimilados como por ejemplo el que ofrece una cuenta de Microsoft).

Hola a todos, y de antemano muchas gracias por toda vuestra ayuda que me podais dar, ya que me es muy necesaria para poder acabar una aplicacion que estoy desarroillando.

Bueno el problema que tengo ern la aplicacion es que al transformar una Venta de Caja en Factura, si esta es la primera funciona perfectamente el pase de las lineas de VENTAS CAJA a FACTURACION anexa perfectamente y despues anula las ventas Facturadas, pero a partir de ese momento los siguientes traspasos de VENTAS a FACTURAS, ocurre que por cada una de las lineas ya existentes en la Tabla de lineas de Facturacion crea por cada una de estas lineas las nuevas Lineas que son trapasadas.

Borrar antes las ventas ya registradas para comprobar el mal funcionamiento que ya se produce a partir de la segunda venta que es traspasada.

Os adjunto una miniBD comprimida con uno de los procesos de la aplicacion de traspaso a Facturacion.

La aplicacion tiene muchos enlaces que son facturados directamente:,Caja, Mostrador, Pedidos, Eventos, Presupuestos..etc, pero creo que si se hacer funcionar uno sabre aplicarlo al resto de los apartados.

Descripcion de las tablas:
VENTAS CAJA
Clientes Tickets --> Cabecera ventas Caja
Lineas Ventas (Contado) -> Lineas Ventas Caja

FACTURACION
(A) CAB FACTURAS (PROV) -> Cabecera Facturas
(A) LIN FACTURAS (PROV) -> Lineas Facturas

Os agradezco de antemano toda la ayuda que podais darme.
Estoy a vuestra disposicion para cualquier aclaracion que necesitais mia.
Un saludo, y de nuevo muy agradecido por todo.

• GESTION-COMERCIAL.rar(4,4 MB)

Una ojeada superficial (la consulta que denominas 'anexar ventas contado') permite ver la incongruencia del código.

Lo primero es que en una relación dependiente y de uno a varios, primero se ha de crear el elemento de la parte uno y creado este el/los de la parte varios (de forma natural: sin padres no hay hijos).

Lo que implica que ese trasvase de datos ha de hacerse en dos etapas INDEPENDIENTES o el resultado será el que se esta obteniendo.

La primera etapa seria crear la factura (su cabecera) y asignarle el numero
La segunda, insertar las líneas tomando como referente el numero de factura antes generado y asentado.

La ojeare con mas detalle, porque es muy probable que sin modificar mucho sobren tablas y trasvases de datos, simplemente se necesitaría un campo que indicase si la línea esta facturada (a la par que indicase a que factura pertenece) y sin duplicidad de ningún tipo (simples consultas de actualización) se tiene el histórico de movimientos (por ejemplo presupuestos, albaranes ...) a la par que facturas consumadas.

En ese ámbito el indicador de que una línea esta 'facturada' seria el testigo de que no es editable o facturable nuevamente (por poner unos ejemplos)

Muchas gracias, espero tu contestatacion cuando veas el funcionamiento.
Un saludo

Creo que le falta un montón de trabajo para ser una aplicación amable con el usuario

No voy a entrar en la critica por criticar, solo puntualizare algunos detalles que considero inadecuados

Lo primero es que darle a cada campo de una tabla un nombre ... es un método que no conlleva ninguna ventaja, si en la tabla principal (cabeceras de facturas) se le llama al campo que tiene el indicador de factura de una forma, alla donde se copie su contenido debería llevar el mismo nombre (el apellido los distinguirá y el apellido es: el nombre de la tabla que lo contiene)

Así Access los podrá proponer como relacionables (si además del nombre, comparten el tipo, algo tan sencillo como copiar de una a otra tabla el diseño)

Lo segundo es que si vamos a trabajar en un campo con datos de tipo TEXTO, aun en el caso de que todos sus caracteres sean numéricos el campo en su diseño debería ser de texto (apreciaras en el documento adjunto, que esos dos detalles están modificados).

Por cierto le he dado al campo una longitud de 8 caracteres (cuatro del año + cuatro del numero formateado), pero pueden ser mas, eso limitara el numero de facturas a 9999, quizás si se menudea mucho sean insuficientes (800/mes menos de 28/día)

La modificación del código, va desde la línea 11 a la 25 comentarios aparte, las líneas que ejecutan el proceso (un poco sucio por los rastros que deja al borrar las líneas actuales), pero es un diseño impuesto son:

Línea 18: genera el numero de factura (se aprecia claramente que es un dato de tipo texto)
Línea 20: Se inserta (crea) el registro cabecera de factura
Línea 22: se insertan las líneas del detalle
Línea 24: se borrar las líneas que se pasan a factura

... no vendría mal detrás del borrado el ejecutar un Requery para evitar las presentaciones de elementos borrados
.- Las tablas deberían tener como requeridos aquellos datos indispensables
.- Seleccionado un elemento con el localizador, el campo 'cantidad' debería recibir el foco ( y no estaría mal predeterminar una cantidad que seria modificable)

.. lo dejo aquí (es tu diseño y asumo que esta adaptado a tu necesidad)

Plantéate una simple cuestión:
Un cliente cambia de domicilio
Te lo comunica y cambias sus datos
El cliente (por esas cosas de la vida o por cualquiera otra causa) solicita una copia de factura anterior al cambio....¿serias capaz de dale algo que no sea una copia de la que ya paso por el departamento de contabilidad y esta marcada como tal?.

Adjunto un documento en PDF creado con esa útil herramienta que Access incorpora (el DOCUMENTADOR)

• Gestion_comercial.zip(125,7 KB)

Hola como estas?.

Se que tienes toda la razon, .... empece a trabajar con Access sin conocerlo y saber sus posibilidades y la verdad es que desconocia la trayectoria que ha tenido todo su desarrollo y veo que es muy manejable.

Hoy en dia haria completamente diferente el analisis y el montaje de todos los procesos que he desarrollado porque realmente hay incoherencias por todos los lados. Pero me encuentyro ya al final de acabar este programa y me es imposible el reestructurar todo para poderlo atacar desde otra manera tanto en tablas como en campos y procesos.

Lo ultimo que me falta para acabar del Programa es el poder pasar a facturas los diferentes procesos de ventas que tiene la aplicacion y una reestructuracion total me es ahora ya imposible realizarla. Pero como me has comentado anteriormente esta lleno de lagunas que dificultan el tratamiento y estoy completamente de acuerdo contigo en todo lo que me has explicado.

Ya solo necesito el poder pasar las lineas de ventas a Facturacion y me es necesario el hacerlo desde lo que tengo ya acabado, porque hay varios lugares diferentes desde donde se puede convertir en factura un documento y es lo ultimo que me falta ya por terminar.

Si no te es mucha molestia mira de que manera podria a traves de una consulta de Anexacion o a traves de otra funcion que creas mas oportuna el poder transfeir las lineas a la tabla de facturacion.

Muchas gracias por tu ayuda y por todos tus consejos.

Un saludo, espero cuando pueda,s me digas algo de como actuar.

Son cuatro míseras líneas, lo único que las diferencia de las que crea Access con el generador de consultas esta en que los referentes son relativos (Me.[nombre del campo]) y en el generador de consultas son absolutas (Formularios.[nombre del formulario].[nombre del campo]).

En cualquier formulario que se utilicen, basta con cambiar (tras el 'Me.') el nombre del campo que represente al dato que se necesita y si los orígenes (las líneas a facturar) son los mismos así como el destino (las facturas) todo debería funcionar sin problemas.

Si se desea ver (para después recrear) las consultas en el generador que Access incorpora, bastara sustituir las rutas absolutas por las relativas y fin de la historia de una aplicación que nace en formato cadáver.

Me queda algo atrás, para que esas líneas sean 'funcionales' en la actual aplicación, basta sustituir el nombre del campo que (en las líneas de factura) tiene el numero de la factura (creo que solo hay una variación)

Que no se modifique el tipo de campo (a texto) es opcional (lo bien hecho tiene mas futuro)

¿Admites un consejo?....

En tiempo de diseño no utilices el método 'Execute', aplica (y sin ocultar advertencias) DoCmd.RunSQL pues en el caso de un problema indicara la causa
Cuando todo funcione adecuadamente o bien se ocultan las advertencias o se aplica el método Execute (la SQL no hay que modificarla)

Disculpa.. Lo siento pero no he entendido bien tu respuesta, me podrias devolver la BD que te mandado con la modificacion ya realizada y asi veria el resultado y como tendria que acoplarlas al resto del programa?.

Te refieres en tu respuesta que he de modificar la Consulta de Anexion?

Referente a tu consejo te dire que he ido mirando ejemplos de aplicaciones y buscand por internet como hacer marchar a Access porque como te habia comentado antes nunca habia trabajado con este sistema.

Siento las molestias que te estoy ocasionando. Gracias

He intentado modificar lo mínimo posible para evitar incompatibilidades con lo que ya tengas, ello me ha obligado a crear dos bases una para una demostración con VBA (que en teoría es lo que se ansiaba) y la otra llamando a consultas guardadas.

Desconozco que interferencias podrá haber con el resto, pero por el diseño apreciado no debería haber ninguna dado que los objetos están muy personalizados (no se puede tan siquiera compartir el formulario de localización de artículos, la causa: exige un formulario especifico para insertar datos), en aras al respeto a su creador he preferido duplicar la base y adecuarla.

He dejado las anteriores consultas y anteriores formularios (los : copia de ....) para que tu (como creador y conocedor de ellos) compares y aprecies diferencias, sobre todo con respecto a los orígenes de datos y la trampa que hubo que hacer para poder asignar el id autonumérico (recién creado) como dato en la relación al generar la inserción mediante una consulta guardada.

Suerte, creo que vas a necesitar mucha para poner en producción a la aplicación si no se planifica un diseño mas eficiente (independiente de que se utilice Access o cualquier lenguaje de programación)

No sabes el enorme esfuerzo que me ha costado el no romper todo y empezar de cero (incluso me hubiera supuesto una decima del tiempo empleado), ha sido similar a pedirle a un medico que no utilice mas que esparadrapo para curar un ataque al corazón ...

• GESTION_VBA.zip(6,6 MB)

Muchas gracias, funciona perfectamente todo en el traspaso de Ventas contado a Facturacion.

He adaptado las modificaciones al Programa principal y me funciona perfectamente.

Ahora intentare adaptar todo lo que has variado en el programa al resto de apartados donde he de pasar a Facturacion y espero que siguiendo tus variaciones pueda hacerlo funcionar en todos los apartados que son bastantes donde se da la circuntancia que una venta, presupuesto, pedidos.. etc, pueden convertirse en factura.

Se que el analisis de toda la gestion deberia de estar planteada de otra manera y si empecese hoy de nuevo una aplicacion partiria de conceptos totalmente diferentes.

Es mi primera aplicacion que he hecho con Access y todo ha sido a base de buscar informacion para poderlo acabar y se que el planteamento deberia de haber sido de otra forma,pero desconocia su buen funcionamiento.

Muy agraecido por toda tu ayuda.
Un saludo

Solo una pregunta mas que igual es ya abusar de tu confianza.

Tengo problemas en el INSERT INTO en uno de los Apartados que he de darle el codigo del Cliente, y me da me da error de sintaxis.

Esto es lo que estoy dando en la instrucccion y me rechaza la forma de darle el codigo del cliente, me da error, porque si le meto un numero de Cliente directamente me funciona perfectamente.

He probado de muchas formas de dar ese dato y en todas me da error. Me podrias decir donde esta el fallo?.

Formulario: PEDIDOCABECERAEMPRESA
Campo Tabla: IdCliFac
Nombre Tabla: PEDIDOCABECERAEMPRESA

CurrentDb.Execute "INSERT INTO [(A) CAB FACTURAS (PROV)] (IdCliFac,FechaFacDef,EstadoCobro,NumFacDef) VALUES (" & Me.PEDIDOCABECERAEMPRESA_IdCliFac & ",#" & Format(Date, "mm/dd/yyyy") & "#,'COBRADO'," & Me.NumFac & ")"

De esta Forma me funciona perfectamente:
CurrentDb.Execute "INSERT INTO [(A) CAB FACTURAS (PROV)] (IdCliFac,FechaFacDef,EstadoCobro,NumFacDef) VALUES (31,#" & Format(Date, "mm/dd/yyyy") & "#,'COBRADO'," & Me.NumFac & ")"

Muchas gracias por todo. Un saludo

Me. es una referencia implícita al formulario u objeto donde se utiliza, por lo que el nombre del formulario no viene al caso (sea cual sea, Me. lo representa)

Como se llama el campo en su origen (consulta o tabla) es absolutamente indiferente, lo importante es: como se llama el objeto del formulario que contiene ese valor (dado las muestra puede ser 'cuadro de texto 33' por poner algo)

Si es un numero ... sin problemas, si es un texto se le añadirán los indicadores (como se le aplican a: contado)

Muchas gracias por todo y por esta aclaración.
Un saludo

UNA CONSULTA COMO LO HAGO PARA AGREGAR DECIMALES,

¿Escribiendo SIN GRITAR? para comenzar .....

Para que algo admita decimales, el campo que lo soporta debería admitir decimales
Para mas datos: ser un poco mas claro, la pregunta en si es ambigua.