![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Opciones...
Gracias newtron;
Entonces supongo que de esa forma no hay responsabilidad por mi parte. Es como si por ejemplo por ley los tickets no pueden pasar de x importe y yo en el programa incluyo en la configuración la opción para que el usuario active o no el limite y especifique el mismo. Eso sería lo correcto, ¿no? Porque de esta forma podrá cambiarlo si la normativa lo hace también. Quiero decir con lo anterior que, el que el programa tenga las posibilidades no va a suponer nunca un problema para mi, ¿cierto? En cuanto a lo de imprimir, ¿Que tal si coloco 2 comandos? 2 opciones: “Imprimir Original” e “Imprimir copia”. Y lo mismo, el usuario ya que imprima lo que quiera según sea para el cliente, para él, para presentarla donde quiera que sea y se exija la palabra copia…. Dando opciones, supongo entonces que no hay problema. Ya es responsabilidad del usuario, ¿O no? “abogadooo!!, ¿estas allí? abogadoo!!. Sal ratita quiero verte la colita!". No es lo mismo que incluir un comando donde cuadres lo vendido a conveniencia. Con esto si que se podría llegar a necesitar un abogadooo, y no para consultas precisamente. Vamos, que lo que yo quiero es hacerlo de forma que el programa no infrinja ninguna ley que pueda suponerme problemas. ¡Un saludo! |
|
#2
|
||||
|
||||
|
Cita:
![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#3
|
||||
|
||||
|
Jaja, gracias Casimiro por tu afilada respuesta. Ya me quedó claro, gracias a todos
![]() |
|
#4
|
||||
|
||||
|
A un cliente que usaba un software de un tercero que permitía hacer eso le llegó una revisión de hacienda y tuvo muchos problemas porque aunque lo hizo sin dolo lo que estaba haciendo no era legal: Emitía la factura con fecha tal e importe tal, la reportaba al fisco mensualmente como siempre, si el cliente le decia que no era el importe acordado o que la fecha o que se yo, la modificaba en su sistema y se la volvía a hacer al cliente para poder cobrarle. Obviamente ya no era lo mismo que se había declarado al fisco y sopas perico.
Con la de facturación electrónica sucede todavía mas chistoso, ya ven que se genera una "cadena original" que contiene los datos de la factura, se digiere y genera un hash el cual se cruza con el proveedor que sella digitalmente la factura. Pues ya hay varios softwares por ahí que te permiten cambiar lo que sea de la cadena original sin importar que ya no pasará la validación subsecuente. Pero bueno, así esto, pero no está por demás colocar en los documentos entregables una renuncia a cualquier reclamo por parte de cliente si es que te pidió algo ilegal (sabiéndolo o no). Yo así, hago "el cliente manifiesta que las operaciones realizadas por el software que se le entrega en propiedad (cuando damos fuentes) se basa única y exclusivamente en solicitudes suyas por lo que libera a al proveedor, al cual sacará a buen resguardo de cualquier responsabilidad legal relacionada con dichas solicitudes, mismas que el proveedor aplicó, programó y desarrollo de buena fe y en atención al contrato preestablecido.
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
|
#5
|
||||
|
||||
|
Casimiro, siguiendo tu analogía, supongamos que en x país los fabricantes de cuchillos tengan que imprimir un num de serie a cada cuchillo. Llega un cliente con mucha $$$ y pide un lo de varios millones (ve tu a saber para queq uiere tantos) pero le pide al fabricante que vayan sin el mentado numero.
Ahora bien hay otro fabricante en el mismo país, que siempre los ha hecho igual y no graba ningun numero de serie pues no está enterado de que tiene que hacerlo, la ignorancia de la ley no lo exime de cumplirla. Si como desarrollador solo nos tiramos hacer lo que el cliente pida podemos caer en casos en donde violamos sin saber alguna ley y ahi les dejo un piloncito...En México se promulgo una ley para el tratamiento de datos personales en forma digital, que pocos clientes y muchos menos desarrolladores han leído esto Tiene varias implicaciones pues el simple hecho de contar digamos con un listado de clientes ya entra dentro de lo que abarca dicha ley. Pero creo que es motivo de otro hilo
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
|
#6
|
||||
|
||||
|
Pues el cuchillo puede tener número de serie o no tenerlo, da igual, el fabricante no tiene la culpa de lo que hagan con su cuchillo
![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#7
|
||||
|
||||
|
Claro Casimiro, no tiene culpa, eso está claro. Tu analogía me ha recordado la peli “El Jurado”. Pero entiendo lo que quiere decir AzidRain y lo de “…la ignorancia de la ley no lo exime de cumplirla” es precisamente lo que yo busco, conocerla.
Lo de la protección de datos ¿como sería en este caso? Si es que es aplicable, claro. Es el usuario, ¿el dueño de la tienda quien debe cumplirlo con sus clientes? ¿Como afectaría eso al TPV que yo creo? Os estoy cosiendo a preguntas, pero aquí quedará el hilo para quien lo necesite. Además, al final tendré que informarme bien a fondo con algún contable, abogado…Vamos, lo que ya habéis comentado de que hay que arrimarse a un experto en x tema si quieres hacer un programa sobre ese tema. Y prometo meter aquí la info para que sirva a todos. Gracias, ¡Un saludo! |
|
#8
|
||||
|
||||
|
Veamos si me explico, evidentemente no vas a poner en el programa una opción que diga algo así como: "Relación de facturas no declaradas".
Pero sí tendrás seguramente más de una serie de facturas y, si quiere el cliente, podrá usar una de las series para llevar facturas que no quiere declarar o para cualquier cosa legal o ilegal, pero eso es algo que tú no tienes por qué controlar ni saber. En cuestiones legales sobre protección de datos es muy particular a cada país, aquí (España) hay unas normas bastante estrictas, aunque casi nadie cumple ![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#9
|
|||
|
|||
|
Cita:
En tal caso se pone en duda la efectividad de mi desarrollo al haber llamadas que no se registraron y que al generar los reportes correspondientes no checa con la facturación del proveedor de telefonía, pero..... en las clausulas de compra yo siempre he puesto que ningún sistema de ese tipo puede llegar al 100% de efectividad por varias razones incluyendo la que he mencionado. Con ésto quiero decir que aunque no seas el culpable siempre habrá quien quiera hacerte ver como culpable. Saludos |
|
#10
|
||||
|
||||
|
Hace un buen tiempo había comentado un caso real que se dio por mi tierra. En un negocio le cae una auditoría y se comprueba que el tipo estaba negreando (truchando). Antes las preguntas de los auditores les dijo quien le proveía el Software. El cuento termina con un informático en cana (cárcel).
Existen leyes, y guste o no hay que cumplirlas. Y como dicen Azid, el desconocimiento de éstas no nos exime ante alguna violación... No siempre tiene la culpa el cliente que lo usa para negrear... seguro que hay más de un cliente que pide un software exclusivamente diseñado con funciones no santas. Como desarrolladores debemos mantenernos a la ley, y hacer oídos sordos a eso (bueno, en realidad... no hay que hacer oídos sordos; porque bajo la ley tu estás teniendo pleno conocimiento de las intenciones y te conviertes en un cómplice del delito o intento de delito y deberíamos denunciarlos) Por algo he dicho: hay que asesorarse... ¡que no basta con hacer el software como salga! y por algo, y para algo, es que están los abogados, y demás expertos en información. Se supone que son actores del proyecto, secundarios quizás, pero actores en fin. Saludos, |
|
#11
|
||||
|
||||
|
Cita:
![]()
__________________
Be water my friend. |
|
#12
|
||||
|
||||
|
Bajo ese contexto mucho no se puede hacer... Y si, "pues eso". El fabricante no tiene la culpa, obviamente.
El problema está en cuanto se pretende llevar este mismo contexto a situaciones en donde no son tan simples y las cosas, quieran o no apreciarlo, son diferentes. No se dijo en ningún momento que uno es culpable si el tipo usa tu sistema para algo ilegal. Pero si se puede ser culpable de que exista esa posibilidad en tu sistema. Para ello, y por ello, es que en los contratos y licencias se incluyen (o deberían incluir) apartados de renuncias en cuanto se escapa de las situaciones esperadas. Se ha dicho que no debemos ignorar que hay una ley, e incluso que hay organismos que certifican de que nuestros desarrollos cumplen con las normas. Quizá lo que nos deberíamos preguntar es porqué no existe cierto "contrato" para con los fabricantes de cuchillos... y porqué los informáticos si debemos tener contratos con cláusulas de renuncias de culpabilidad explícitamente escritas. ![]() Saludos, |
|
#13
|
||||
|
||||
|
Cita:
De una forma o de otra no vendría mal la aportación de algún abogado. ¿Hay alguno en la sala? ah... no... eso se pregunta cuando a alguien le da un síncope y se busca a un médico. ![]()
__________________
Be water my friend. |
|
#14
|
||||
|
||||
|
Realmente no tiene mucho sentido que se le implique al fabricante.
Si yo llevo la contabilidad con la PDA ( Papel De Apuntar) puedo hacer pufos. No por ello van a imputar al fabricante de folios y al fabricante de bolígrafos. Es decir, es un comportamiento fraudulento del titular o del responsable de la empresa, no del fabricante del mismo. Y si llevo las cuentas con el ERP del siglo XXI , microsoft Excel ?? Imputarían a Miguelito Puertas ? Saludos
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
|
#15
|
||||
|
||||
|
Respuesta de un abogado:
"En primer lugar y como carácter general quiero informarle de que cualquier infracción que se produzca en la emisión de facturas es responsable del emisor de las mismas, no del software que las emite. Es cierto que dicho software ha de estar adaptado a normativa vigente, y ser útil para al cliente, pero no genera responsabilidad para el fabricante el hecho de que dicho software produjera alguna factura con número o fecha incorrectos, etc. La responsabilidad es la del emisor, que no puede excudarse en error del software y que si el mismo fuese inútil, podría reclamarles la devolución del mismo, sino cumple las expectativas para que fue creado, pero no le generaría más responsabilidad más allá de esto." "En relación a la certificación, decirle que la calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, MoProSoft...) Para certificarlo, tendría que ponerse en contacto con La Asociación Española de Normalización y Certificación (Aenor) que es una entidad dedicada al desarrollo de la normalización y la certificación (N+C) en todos los sectores industriales y de servicios. A través de este link tendría su contacto: (no puedo poner links todavía, pero vamos: 'GOOGLE' + 'AENOR') Bueno, está claro entonces que la fabrica de cuchillos no tiene responsabilidad si alguien le rebana un dedo a otra persona y se hace un llavero. Pero tampoco puede llevar un botón que diga: "limpiar huellas y sangre humana ajena" También me ha dicho que la numeración ha de ser correlativa tanto en número como en fecha y empezar por el 1 a cada nuevo ejercicio. Además, no hay que establecer ningún limite para los tickets. Gracias de nuevo a todos ![]() |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Modificar las fechas de creación y modifiación de un archivo | lduron | Varios | 5 | 06-07-2011 02:13:19 |
| Emisión video internet. 32 canales | rabata2001 | Internet | 1 | 22-03-2011 10:48:07 |
| Factura Electronica Factura-E | keys | Varios | 1 | 09-11-2010 06:37:46 |
| slq entre dos fechas comparar fechas | taru | MySQL | 2 | 30-07-2007 16:10:36 |
| Fallo Nº Factura y Linea Factura | CarmaZone | Tablas planas | 5 | 26-05-2005 11:17:19 |
|