Access - Nosuma en vista de diseño

creo una consulta de selección y la abro en vista de Diseño, para indicar fichero y criterios de selección, le indico que campos sumar y no suma, solo indica en cabecera de campos (suma y nombre de campo) , no se porque no suma, tenéis alguna idea------gracias

En su 'vista diseño' es normal que no presente resultados, lo hará cuando se ejecute.

Una consulta de selección no suele sumar (con la excepción de que se utilice una función de dominio), para que sume debería ser una consulta de datos agrupados.

Es posible que existan diferencias semánticas, lo ideal es que se publicase la SQL de la consulta (con el fin de 'hablar el mismo idioma')

logicamente es cuando se ejecuta que no presenta sumas

Cuando indicas Totales en diseño, indica Campo, Tabla Total Orden, en total se despliega Agrupar por, suma, promedio etc.

Entiendo que tendría que sumar los campos seleccionados, en algún tutoríal así lo indica

Las operaciones que se efectúan (en los diseños agrupados) lo hacen sobre la columna (afectan a cada columna de forma independiente) ¿a que tipo de selección se hace referencia? ...

Reincido en mi anterior observación, publicar la 'Vista SQL' de esa consulta, proporcionaría datos mas fidelignos que la semántica que se utilice (se evita estar adivinando o deduciendo, cuando existen diferencias conceptuales)

Y una consulta en vista SQL NO PRESENTA DATOS (ni reales ni imaginarios) solo el esquema de lo que se pretende hacer con ellos (que en definitiva es lo que se pregunta, como 'se tiene que plantear' para llegar al resultado deseado).

Paso las sentencias SQL

Hay cuando menos dos detalles que me llaman la atención:

Uno es el campo que se define asi: Facturas(Numero Cliente)
Normalmente Access no 'espera' que el nombre de un campo contenga espacios y cuando los contiene que se le indique encerrándolo entre corchetes (para que lo considere un conjunto único), si además ese nombre de campo contiene paréntesis .... al motor de análisis de Access se le puede complicar y devolver ... cualquier cosa

Lo normal seria así (para ese campo en concreto si se dan esa curiosas circunstancias (nombres que no respetan las normas): [Facturas(Numero Cliente)]

Al respecto de la suma, creo que el enfoque utilizado no es correcto, pues aunque se le indique 'que sume' también se le indica que los registros se agrupen por Id de factura (un dato generalmente UNICO y como tal no agrupable), por el numero de factura (otro campo que también puede ser único ....) y finalmente por el campo que si seria agrupable (el cliente) ....

Así no funciona (ni Access ni cualquiera otra base de datos), pues todas ellas sumaran 'los conjuntos agrupables' (el/su subgrupo) no conjuntos de conjuntos (los cuales implicarían una doble agrupación que se traduciría en una nueva consulta sobre esa consulta).

Dos opciones que dependerán de los datos reales, esto es, del diseño de las tablas (u orígenes de datos).
Una:
Agrupar para formar los conjuntos a sumar (por ejemplo, solo por factura o cliente u aquellos campos que formen subconjuntos, pero no utilizando JAMAS datos UNICOS que por definición no se pueden agrupar), para luego generar una nueva consulta en base a los resultados obtenidos y añadir (ya sin agrupaciones) el resto de los datos necesarios, en base a datos comunes y relacionables (por ejemplo cliente o factura).

Dos:
Si una 'factura' se compone de diversas partidas, descomponer esa tabla en dos, por una parte los datos comunes (factura, fecha, cliente, dirección ... etc), por otra los detalles relacionados (las partidas, normalmente relacionadas por el numero de factura o el ID, que ahora ya tiene sentido) y efectuar las sumas sobre esos datos.

En fin, que Access suma (lo sabe hacer y lo suele hacer bien), pero como cumple exactamente lo que le ordena, suma en este caso lo que se le indica: subconjuntos únicos (que como son únicos es lo mismo que si no sumase), pero no es problema Access, sino de usuario y su planteamiento.